Update the Exchange Online PowerShell module when you need a newer build, and check the installed version before you run production automation. Old builds can break sign-in flows, cmdlet behavior, or scheduled scripts, which wastes time and can interrupt mailbox administration. This guide covers version checks, safe update steps, and a fallback plan for failed installs or authentication errors. For the latest Microsoft guidance, see techcommunity.microsoft.com.
What you need before you start
Before you update, confirm which shell you are using, whether automation depends on a pinned module version, and whether the module is installed in the scope you expect. Those checks help you avoid a version change that breaks a scheduled job or a remote sign-in path.
How do you update the module?
Use PowerShell Gallery as the source, update the package in the same scope where it is installed, and then restart the session.
Choose the scope first
Use -Scope CurrentUser when you do not have local admin rights or when the module is only needed for one account. Use an all-users install when a shared management workstation or automation host needs the same module for every account.
- Open PowerShell with the same shell type you intend to keep using.
- Run Update-Module ExchangeOnlineManagement for an existing install in the same scope where it is installed.
- If update does not find the module, run Install-Module ExchangeOnlineManagement -Scope CurrentUser or, in an elevated session, Install-Module ExchangeOnlineManagement -Scope AllUsers.
- Close PowerShell and open a new session before connecting again.
- Recheck the version with Get-Module ExchangeOnlineManagement -ListAvailable.
How do you check the installed version?
Use Get-Module ExchangeOnlineManagement -ListAvailable to read the local version. Check again after reinstalling or updating, because stale sessions can still load an older copy from memory or a different profile path.
Version comparison
| Version state | Meaning | Next action |
|---|---|---|
| Current release | Module is installed and available to the shell | Test sign-in and automation |
| Older release | Module is installed, but may not match your script requirements | Plan an update and validate scripts |
| Not listed | No local copy is available in the current session context | Install the module before relying on it |
Suppose a nightly script still loads one copy from a user profile while your admin console shows a different copy. That mismatch usually means two installs exist. Remove the old scope or pin the script to the required version until you can standardize it.
Exchange Online checklist table
This checklist separates shell choice, install scope, and sign-in recovery so you can avoid mixing steps that only work in one environment. Use it as a preflight pass before you touch production automation.
| Environment | Prerequisite | Command to run | Expected result | Next action |
|---|---|---|---|---|
| Windows PowerShell 5.1 | Module is installed in the expected scope | Get-Module ExchangeOnlineManagement -ListAvailable | One or more versions return | Run Install-Module or Update-Module |
| PowerShell 7 | ExchangeOnlineManagement is installed | Get-Module ExchangeOnlineManagement -ListAvailable | Module version is shown | Reconnect and validate the connection |
| Current-user install | No admin rights needed | Install-Module ExchangeOnlineManagement -Scope CurrentUser | Module installs under the user profile | Open a new session and verify the version |
| All-users install | Elevated session | Install-Module ExchangeOnlineManagement -Scope AllUsers | Module installs for all accounts on the host | Confirm the shared path and test sign-in |
| WAM-disabled sign-in | Interactive auth fails in the Windows account flow | Connect-ExchangeOnline -DisableWAM | Sign-in prompt opens without WAM | Keep the switch only where WAM blocks access |
How do you connect after updating?
Use Connect-ExchangeOnline after the module update, not before. It is the primary connection cmdlet and it supports -UserPrincipalName for explicit identity selection. -SkipLoadingFormatData can speed startup in some sessions.
Connection options
- Run Connect-ExchangeOnline -UserPrincipalName admin@contoso.com when you want a specific account prompt.
- Add -SkipLoadingFormatData if the session does not need full formatting data immediately.
- Use certificate-based authentication for automation where interactive sign-in is not appropriate.
- If Windows sign-in fails, retry with -DisableWAM.
Picture a helpdesk admin whose sign-in window never appears, while the same command works in another PowerShell session. That pattern often points to WAM rather than a bad module install. Switch to -DisableWAM before you reinstall anything.
Common mistakes
The most common failures come from skipped version checks, mixed shell instructions, and assuming the newest module will fit every script unchanged.
- Installing only ExchangeOnlineManagement and skipping a version check afterward.
- Following a PowerShell 7 guide inside Windows PowerShell 5.1, or the reverse.
- Treating WAM sign-in errors as a module corruption issue.
- Updating the module without verifying the version afterward.
- Moving automation to a new release without a rollback copy of the previous package.
How do you recover from a failed install?
Start by checking whether the module is installed in the scope you expect, then reinstall it in the correct scope. If sign-in still fails after a clean install, switch the authentication path instead of repeating the same command. That sequence handles the common causes without changing more than one variable at a time.
- Run Get-Module ExchangeOnlineManagement -ListAvailable again.
- Reinstall with the correct scope: -Scope CurrentUser or -Scope AllUsers.
- Restart PowerShell and verify the module version again.
- If interactive sign-in still fails, retry with -DisableWAM.
For automation, keep one known-good version available until the new build passes a real sign-in and cmdlet test. That is the safest way to pin a version during a transition window.
Frequently asked questions
How do I update the Exchange Online PowerShell module?
Run Update-Module ExchangeOnlineManagement in the same shell that loads your scripts, then restart PowerShell and verify the version with Get-Module ExchangeOnlineManagement -ListAvailable. If the module is not already present, use Install-Module from PowerShell Gallery with the scope that matches your setup.
What is the latest version of the ExchangeOnlineManagement module?
Check the installed copy with Get-Module ExchangeOnlineManagement -ListAvailable. Compare the result against the version your environment requires, then reopen the shell if the displayed version does not match the one you just installed.
How do I get the exchange online PowerShell module?
Install it from PowerShell Gallery with Install-Module ExchangeOnlineManagement. Use -Scope CurrentUser for a single account or -Scope AllUsers in an elevated session for shared machines. Then open a new shell and check the version before connecting.
What command updates the Exchange Online PowerShell module?
The update command is Update-Module ExchangeOnlineManagement. If that fails because the module was not installed through PowerShellGet, reinstall from PowerShell Gallery instead. Afterward, confirm the result with Get-Module ExchangeOnlineManagement -ListAvailable so you know which copy PowerShell loads.
How do I install the Exchange Online PowerShell module for all users?
Open PowerShell as an administrator and run Install-Module ExchangeOnlineManagement -Scope AllUsers. That places the module where every account on the host can load it. After installation, verify that the expected version appears in Get-Module ExchangeOnlineManagement -ListAvailable.
How do I check which version of the module I have installed?
Use Get-Module ExchangeOnlineManagement -ListAvailable. It shows every available local copy. Compare the result to the version your environment requires, then reopen the shell if the displayed version does not match the one you just installed.