PowerShell for Microsoft 365 Administration: Why the GUI Isn't Enough in 2026

Every Microsoft 365 admin eventually hits the same wall. The admin center works fine for creating one user or checking one mailbox — then someone asks for calendar permissions across 200 mailboxes, a list of every inbox rule that forwards mail externally, or proof that no account has skipped MFA registration, and the portal simply has no button for it. That is not a gap Microsoft forgot to fill. The web consoles are deliberately a subset; PowerShell is the actual management surface of Microsoft 365, and the portals are a friendly window onto part of it. This article explains why that remains true in 2026, maps the module landscape after the biggest tooling shake-up in a decade, and shows where PowerShell earns its keep in day-to-day administration and security operations.

The short answer

PowerShell matters for three reasons that have not changed and one that has. The constants: scale (anything you can do once, you can do 10,000 times in a loop), coverage (hundreds of settings — calendar rights, mailbox delegation details, CAS settings, per-user auth methods — are exposed only through cmdlets or the Graph API), and evidence (a script produces a repeatable, timestamped, exportable record, which clicking through blades never will). The change: since the MSOnline and AzureAD modules were retired in 2025, admin scripting has consolidated onto the Microsoft Graph SDK and a small set of REST-backed modules — so the skills now transfer cleanly across the productivity suite, the security suite and automation platforms. If your scripts still start with Connect-MsolService, they have already stopped working.

The 2026 module map

This is the current, supported toolkit — what to install, what it covers, and what it replaced:

Intune has no dedicated module — device management is Graph, managed through the SDK. Defender XDR follows the same pattern: incidents, alerts and advanced hunting are exposed through the Graph security API, so Connect-MgGraph with the right scopes is also your entry point to the security suite. One skill, most of the estate.

What died in 2025 — and why it matters for your scripts

Microsoft deprecated the MSOnline (Msol*) and AzureAD (AzureAD*) modules in March 2024 and switched them off in 2025 — MSOnline stopped working for all tenants by late May 2025, with AzureAD following after July. Two decades of blog-post snippets, runbooks and scheduled tasks built on those cmdlets are now dead code. If you have not audited for stragglers, do it deliberately: Entra ID's recommendations report flags legacy module sign-ins, and a search of your script repository for Connect-MsolService and Connect-AzureAD finds the rest. The practical migration path is either straight to the Graph SDK (more future-proof, more verbose) or the Microsoft.Entra module, which was built for exactly this: alias compatibility means many old scripts run after changing little more than the connect line. Either way the auth model changes with it — modern modules use Entra app registrations with consented scopes, not the ambient full-tenant access the old modules enjoyed. That is more setup, and considerably better security.

What the portal cannot do

The honest case for PowerShell is a list of real Tuesday-afternoon tasks with no GUI equivalent:

• Bulk anything. Set an out-of-office on 40 mailboxes of a departed team, add a proxy address to every user in a department, apply a licence change driven by a CSV from HR. The admin center does these one at a time or not at all.
• Permission auditing. Who has SendAs or full access on which mailboxes? What do calendar permissions actually look like across the org? Get-MailboxPermission and Get-MailboxFolderPermission answer in minutes; the portal cannot answer at all.
• Hunting malicious inbox rules. Enumerating every mailbox's rules for external forwarding or delete-on-arrival patterns — the classic business email compromise persistence trick — is a ten-line loop over Get-InboxRule. There is no console view of everyone's rules.
• Audit log interrogation at scale. Purview's search UI is fine for one question; Search-UnifiedAuditLog feeds an actual investigation — filtered, paged, exported, repeatable.
• Configuration as evidence. Exporting conditional access policies, transport rules and DLP policies to JSON on a schedule gives you drift detection and a point-in-time record for auditors. Screenshots of blades do not survive an ISO 27001 audit; timestamped exports do.
• Scheduled reporting. Inactive accounts, MFA registration gaps, licence utilisation, mailboxes approaching quota — anything you want weekly in a CSV rather than manually on demand.

PowerShell as a security tool

For the security suite, PowerShell moves from convenient to essential. Incident response is the clearest case: when an account is compromised at 2 a.m., the required actions — disable sign-in, revoke refresh tokens, reset the password, kill malicious inbox rules, block the sender, pull the sign-in and audit history — span four different portals. Scripted, they are one sequence executed in seconds, identically every time, with output you can attach to the incident record. That is the design idea behind our Microsoft 365 incident response console in PowerShell, and the scripts live in our open-source PowerShell Security Toolkit on GitHub.

Beyond IR, the same pattern runs through defensive work: conditional access policies managed as exported JSON (policy-as-code, reviewable in a pull request rather than edited live in a blade), advanced hunting queries against Defender XDR through the Graph security API, secure-score and auth-method reporting on a schedule, and Purview content searches that would take an afternoon of clicking. If you want a quick read on where your tenant stands before writing any of this, our free browser-based x365 audit tool surfaces conditional access coverage, MFA posture and legacy-auth exposure without sending tenant data anywhere — and the conditional access gaps guide covers the policies most tenants are missing.

Automating without leaving credentials behind

The step after interactive scripting is unattended automation — and it is where most PowerShell security incidents are self-inflicted. The rules that matter:

• No stored passwords, ever. Unattended scripts should use certificate-based app-only authentication (an app registration plus a certificate, supported by both Connect-MgGraph and Connect-ExchangeOnline) or, better, a managed identity in Azure Automation or Azure Functions, where there is no credential to steal at all.
• Least-privilege scopes. Graph permissions are granular for a reason. A reporting script needs User.Read.All, not Directory.ReadWrite.All. Every scope you consent to is attack surface if the app or certificate leaks.
• Treat scripts like code. Version control, peer review before anything touches production, and no tenant secrets in the repository. A script with Directory-write permissions is an admin account that never sleeps — govern it like one.
• Log what automation does. Unattended runs should write their own audit trail. When something changes 3,000 objects, "which run did that and why" must be answerable.

Getting started: a realistic path

You do not need to be a developer. Start read-only: install the Graph SDK and EXO v3 modules, connect interactively, and rebuild reports you currently do by hand — licence assignments, mailbox sizes, MFA registration. Read-only cmdlets (Get-*) cannot break anything, and they teach the object model. Next, script one real recurring task end-to-end, with a -WhatIf run before every write. Then move a proven script into scheduled automation with a managed identity. Within a quarter you will have a small library that saves hours a week — and the next audit, migration or incident will be the moment it pays for itself. The PowerShell Security Toolkit is a working starting point for the security side.

Frequently asked questions

Why use PowerShell instead of the Microsoft 365 admin center?

Three reasons: scale, coverage and evidence. PowerShell performs bulk operations the portal does one-at-a-time or not at all; it exposes hundreds of settings (mailbox folder permissions, inbox rules across all users, detailed CAS and auth-method configuration) that have no GUI equivalent; and scripts produce repeatable, timestamped, exportable output suitable for audits and incident records. The admin centers are a convenience layer — PowerShell and the Graph API are the full management surface.

Which PowerShell modules should Microsoft 365 admins use in 2026?

The supported set is: the Microsoft Graph PowerShell SDK (users, groups, licences, Intune, conditional access, security), Microsoft.Entra for scenario-focused identity work and AzureAD script migration, ExchangeOnlineManagement v3 for Exchange Online plus Connect-IPPSSession for Purview/Security & Compliance, MicrosoftTeams for Teams, and PnP.PowerShell for deep SharePoint work. The legacy MSOnline and AzureAD modules were retired in 2025 and no longer function.

What replaced the MSOnline and AzureAD modules?

The Microsoft Graph PowerShell SDK is the primary replacement, and the Microsoft.Entra module (generally available since 2025) is the fastest migration path — it is roughly 98% compatible with AzureAD cmdlet names, and Enable-EntraAzureADAlias lets many legacy scripts run after changing little more than the connection line. MSOnline stopped working for all tenants by late May 2025, with AzureAD retired after July 2025, so any scripts still calling Connect-MsolService or Connect-AzureAD are already broken.

Is PowerShell for Microsoft 365 a security risk?

PowerShell is a security asset when governed and a liability when not. The risks are self-inflicted: passwords stored in scripts, over-privileged app registrations, and unmanaged scheduled tasks. The fixes are standard practice: certificate-based app-only authentication or managed identities instead of stored credentials, least-privilege Graph scopes, version control and review for scripts that write to the tenant, and logging of automated runs. Defensively, PowerShell is one of the strongest security tools an admin has — for auditing permissions, hunting malicious inbox rules and executing repeatable incident response.

Can PowerShell manage Microsoft Defender and the security suite?

Yes. Defender XDR incidents, alerts and advanced hunting are exposed through the Graph security API via the Graph PowerShell SDK; Purview (DLP, retention, sensitivity labels, content search, audit log) is managed through Connect-IPPSSession in the ExchangeOnlineManagement module; and Entra security configuration — conditional access, authentication methods, risky users — is managed through Graph or the Microsoft.Entra module. Common security workflows, from Search-UnifiedAuditLog investigations to conditional-access-as-code, are PowerShell-first.

Do I need to learn the Graph API to use Graph PowerShell?

Not to start. The SDK wraps the API in familiar cmdlets (Get-MgUser, Get-MgGroup) with tab completion and standard PowerShell pipelines. Understanding the underlying API helps later — permissions scopes map to API permissions, advanced filtering uses OData syntax, and Invoke-MgGraphRequest covers endpoints without a dedicated cmdlet — but the learning curve begins with ordinary Get commands, which are read-only and safe to explore with.