About the Exchange Online PowerShell module
The Exchange Online PowerShell module uses modern authentication and works with or without multi-factor authentication (MFA) for connecting to all Exchange-related PowerShell environments in Microsoft 365: Exchange Online PowerShell, Security & Compliance PowerShell, and standalone Exchange Online Protection (EOP) PowerShell.
For connection instructions using the module, see the following articles:
- Connect to Exchange Online PowerShell
- Connect to Security & Compliance PowerShell
- Connect to Exchange Online Protection PowerShell
- App-only authentication for unattended scripts in Exchange Online PowerShell and Security & Compliance PowerShell
- Use Azure managed identities to connect to Exchange Online PowerShell
- Use C# to connect to Exchange Online PowerShell
The rest of this article explains how the module works, how to install and maintain the module, and the optimized Exchange Online cmdlets that are available in the module.
Tip
Version 3.0.0 and later (2022) is known as the Exchange Online PowerShell V3 module (abbreviated as the EXO V3 module). Version 2.0.5 and earlier (2021) was known as the Exchange Online PowerShell V2 module (abbreviated as the EXO V2 module).
REST API connections in the EXO V3 module
All available cmdlets in Exchange Online PowerShell and virtually all cmdlets in Security & Compliance PowerShell are backed by a REST API based on the version of the EXO V3 module:
- Exchange Online PowerShell: v3.0.0 or later.
- Security & Compliance PowerShell: v3.2.0 or later.
In Exchange Online PowerShell and in Security & Compliance PowerShell, REST API connections are used by default and require the PowerShellGet and PackageManagement modules. For more information, see PowerShellGet for REST-based connections in Windows.
REST API cmdlets have the following advantages over their historical counterparts:
- More secure: REST API cmdlets have built-in support for modern authentication and don't rely on the remote PowerShell session, so PowerShell on your client computer doesn't need Basic authentication in WinRM.
- More reliable: REST API cmdlets handle transient failures with built-in retries, so failures or delays are minimized. For example:
- Failures due to network delays.
- Delays due to large queries that take a long time to complete.
- Better performance: The connection avoids setting up a PowerShell runspace.
The benefits of REST API cmdlets are described in the following table:
Remote PowerShell cmdlets | Get-EXO* cmdlets | REST API cmdlets | |
---|---|---|---|
Security | Least secure | Highly secure | Highly secure |
Performance | Low performance | High performance | Medium performance |
Reliability | Least reliable | Highly reliable | Highly reliable |
Functionality | All parameters and output properties available | Limited parameters and output properties available | All parameters and output properties available |
REST API cmdlets have the same cmdlet names and work just like their remote PowerShell equivalents, so you don't need to update any of your scripts.
Tip
The Invoke-Command cmdlet doesn't work in REST API connections. For alternatives, see Workarounds for Invoke-Command scenarios in REST API connections.
Consider the following items for connections in remote PowerShell mode:
Remote PowerShell connections are deprecated in Exchange Online PowerShell and will be deprecated in Security & Compliance PowerShell. For more information, see here and here.
Remote PowerShell connections require Basic authentication in WinRM on the client computer. If you don't connect in remote PowerShell mode, you have access to REST API cmdlets only.
A few REST API cmdlets in Exchange Online PowerShell have been updated with the experimental UseCustomRouting switch. This switch routes the command directly to the required Mailbox server, and might improve overall performance.
When you use the UseCustomRouting switch, you can use only the following values for identity of the mailbox:
- User principal name (UPN)
- Email address
- Mailbox GUID
The UseCustomRouting switch is available only on the following REST API cmdlets in Exchange Online PowerShell:
- Get-Clutter
- Get-FocusedInbox
- Get-InboxRule
- Get-MailboxAutoReplyConfiguration
- Get-MailboxCalendarFolder
- Get-MailboxFolderPermission
- Get-MailboxFolderStatistics
- Get-MailboxMessageConfiguration
- Get-MailboxPermission
- Get-MailboxRegionalConfiguration
- Get-MailboxStatistics
- Get-MobileDeviceStatistics
- Get-UserPhoto
- Remove-CalendarEvents
- Set-Clutter
- Set-FocusedInbox
- Set-MailboxRegionalConfiguration
- Set-UserPhoto
Use the UseCustomRouting switch experimentally and report any issues that you encounter.
Use the Get-ConnectionInformation cmdlet to get information about REST-based connections to Exchange Online PowerShell and Security & Compliance PowerShell. This cmdlet is required because the Get-PSSession cmdlet in Windows PowerShell doesn't return information for REST-based connections.
Scenarios where you can use Get-ConnectionInformation are described in the following table:
Scenario Expected output Run before a Connect-ExchangeOnline or Connect-IPPSSession command. Returns nothing. Run after a Connect-ExchangeOnline or Connect-IPPSSession command that connects in remote PowerShell mode. Returns nothing (use Get-PSSession). Run after Connect-ExchangeOnline or Connect-IPPSSession command that connects in REST API mode. Returns one connection information object. Run after multiple REST-based Connect-ExchangeOnline or Connect-IPPSSession commands. Returns a collection of connection information objects. Run after multiple Connect-ExchangeOnline or Connect-IPPSSession commands that connect in remote PowerShell mode and REST API mode. Returns one connection information object for each REST-based session. Use the SkipLoadingFormatData switch on the Connect-ExchangeOnline cmdlet in REST-based connections to avoid loading format data and to run Connect-ExchangeOnline commands faster.
Cmdlets backed by the REST API have a 15 minute timeout, which can affect bulk operations. For example, the following Update-DistributionGroupMember command to update 10000 members of a distribution group might time out:
$Members = @("member1","member2",...,"member10000") Update-DistributionGroupMember -Identity DG01 -Members $Members
Instead, use the Update-DistributionGroupMember command to update fewer members, and then add the remaining members individually using an Add-DistributionGroupMember command. For example:
Update-DistributionGroupMember -Identity DG01 -Members $Members[0..4999] $Remaining = $Members[-5000..-1] foreach ($Member in $Remaining) { Add-DistributionGroupMember -Identity DG01 -Member $Member }
For additional information about what's new in the EXO V3 module, see the Release notes section later in this article.
Report bugs and issues for the Exchange Online PowerShell module
Note
For General Availability (GA) versions of the module, open a support ticket for any problems that you're having. For Preview versions of the module, use the email address as described in this section. You can also use the email address for feedback and suggestions for both GA and Preview versions of the module.
When you report an issue at exocmdletpreview[at]service[dot]microsoft[dot]com
, be sure to include the log files in your email message. To generate the log files, replace <Path to store log file> with the output folder you want, and run the following command:
Connect-ExchangeOnline -EnableErrorReporting -LogDirectoryPath <Path to store log file> -LogLevel All
Note
Frequent use of the Connect-ExchangeOnline and Disconnect-ExchangeOnline cmdlets in a single PowerShell session or script might lead to a memory leak. The best way to avoid this issue is to use the CommandName parameter on the Connect-ExchangeOnline cmdlet to limit the cmdlets that are used in the session.
Cmdlets in the Exchange Online PowerShell module
All versions of the module contain nine exclusive Get-EXO* cmdlets for Exchange Online PowerShell that are optimized for speed in bulk data retrieval scenarios (thousands and thousands of objects). The improved Exchange Online PowerShell cmdlets that are available only in the module are listed in the following table:
Note
If you open multiple connections to Exchange Online PowerShell in the same window, the Get-EXO* cmdlets are always associated with the last (most recent) Exchange Online PowerShell connection. Run the following command to find the REST API session where the Get-EXO* cmdlets are run: Get-ConnectionInformation | Where-Object {$_.ConnectionUsedForInbuiltCmdlets -eq $true}
.
The connection-related cmdlets in the module are listed in the following table:
EXO module cmdlet | Older related cmdlet | Comments |
---|---|---|
Connect-ExchangeOnline | Connect-EXOPSSession in V1 of the module or New-PSSession |
|
Connect-IPPSSession | Connect-IPPSSession in V1 of the module | |
Disconnect-ExchangeOnline | Remove-PSSession | |
Get-ConnectionInformation | Get-PSSession | Available in v3.0.0 or later. |
Miscellaneous Exchange Online cmdlets that happen to be in the module are listed in the following table:
Cmdlet | Comments |
---|---|
Get-DefaultTenantBriefingConfig | Available in v3.2.0 or later. |
Set-DefaultTenantBriefingConfig | Available in v3.2.0 or later. |
Get-DefaultTenantMyAnalyticsFeatureConfig | Available in v3.2.0 or later. |
Set-DefaultTenantMyAnalyticsFeatureConfig | Available in v3.2.0 or later. |
Get-MyAnalyticsFeatureConfig | Available in v2.0.4 or later. |
Set-MyAnalyticsFeatureConfig | Available in v2.0.4 or later. |
Get-UserBriefingConfig | Replaced by Get-MyAnalyticsFeatureConfig. |
Set-UserBriefingConfig | Replaced by Set-MyAnalyticsFeatureConfig. |
Get-VivaInsightsSettings | Available in v2.0.5 or later. |
Set-VivaInsightsSettings | Available in v2.0.5 or later. |
Get-VivaModuleFeature | Available in v3.2.0 or later. |
Get-VivaModuleFeatureEnablement | Available in v3.2.0 or later. |
Add-VivaModuleFeaturePolicy | Available in v3.2.0 or later. |
Get-VivaModuleFeaturePolicy | Available in v3.2.0 or later. |
Remove-VivaModuleFeaturePolicy | Available in v3.2.0 or later. |
Update-VivaModuleFeaturePolicy | Available in v3.2.0 or later. |
Install and maintain the Exchange Online PowerShell module
You download the module from the PowerShell gallery at https://www.powershellgallery.com/packages/ExchangeOnlineManagement/.
The procedures in this section explain how to install, update, and uninstall the module.
Supported operating systems for the Exchange Online PowerShell module
The latest versions of the module are officially supported in PowerShell 7 on Windows, Linux, and Apple macOS.
Specifically, version 2.0.4 or later is supported in PowerShell 7.0.3 or later.
For more information about PowerShell 7, see Announcing PowerShell 7.0.
Apple macOS
The module is supported in the following versions of macOS:
- macOS 11 Big Sur or later
- macOS 10.15 Catalina
- macOS 10.14 Mojave
For instructions on installing PowerShell 7 on macOS, see Installing PowerShell on macOS.
Note
As described in the installation article, you need to install OpenSSL, which is required for WSMan.
After you install PowerShell 7 and OpenSSL, do the following steps:
Run PowerShell as superuser:
sudo pwsh
In the PowerShell superuser session, run the following commands:
Install-Module -Name PSWSMan Install-WSMan
If prompted, accept PSGallery as the source for the cmdlets.
Now you can do the regular PowerShell prerequisites and install the Exchange Online PowerShell module.
Linux
The module is officially supported in the following distributions of Linux:
- Ubuntu 18.04 LTS
- Ubuntu 20.04 LTS
If you have trouble using the module in other distributions of Linux, report any issues.
For instructions on installing PowerShell 7 on Linux, see Installing PowerShell on Linux.
After you install PowerShell 7, do the following steps:
Run PowerShell as superuser:
sudo pwsh
In the PowerShell superuser session, run the following commands:
Install-Module -Name PSWSMan Install-WSMan
If prompted, accept PSGallery as the source for the cmdlets.
Now you can do the regular PowerShell prerequisites and install the Exchange Online PowerShell module.
Note
If you connect to Exchange Online PowerShell from a network that's behind a proxy server, the EXO V2 module (version v2.0.5 or earlier) doesn't work in Linux. You need to use the EXO V3 module (v3.0.0 or later) in Linux to connect from a network that's behind a proxy server.
Windows
All versions of the module are supported in Windows PowerShell 5.1.
PowerShell 7 on Windows requires version 2.0.4 or later.
Version 2.0.5 or later of the module requires the Microsoft .NET Framework 4.7.2 or later to connect. Otherwise, you'll get an System.Runtime.InteropServices.OSPlatform
error. This requirement shouldn't be an issue in current versions of Windows. For more information about versions of Windows that support the .NET Framework 4.7.2, see this article.
Windows PowerShell requirements and module support in older versions of Windows are described in the following list:
Windows 8.1¹
Windows Server 2012 or Windows Server 2012 R2¹
Windows 7 Service Pack 1 (SP1)² ³ ⁴
Windows Server 2008 R2 SP1² ³ ⁴
¹ PowerShell 7 on this version of Windows requires the Windows 10 Universal C Runtime (CRT).
² This version of Windows has reached its end of support, and is now supported only in Azure virtual machines.
³ This version of Windows supports only v2.0.3 or earlier versions of the module.
⁴ Windows PowerShell 5.1 on this version of Windows requires the .NET Framework 4.5 or later and the Windows Management Framework 5.1. For more information, see Windows Management Framework 5.1.
Prerequisites for the Exchange Online PowerShell module
Set the PowerShell execution policy to RemoteSigned
Note
The settings in this section apply to all versions of PowerShell on all operating systems.
PowerShell needs to be configured to run scripts, and by default, it isn't. You'll get the following error when you try to connect:
Files cannot be loaded because running scripts is disabled on this system. Provide a valid certificate with which to sign the files.
To require all PowerShell scripts that you download from the internet are signed by a trusted publisher, run the following command in an elevated PowerShell window (a PowerShell window you open by selecting Run as administrator):
Set-ExecutionPolicy RemoteSigned
For more information about execution policies, see About Execution Policies.
Turn on Basic authentication in WinRM
Note
As described earlier in this article, the information in this section applies to remote PowerShell connections only. Remote PowerShell connections to Exchange Online PowerShell and Security & Compliance PowerShell will be retired. For more information, see here and here. REST-based connections don't require Basic authentication in WinRM as described in this section.
For remote PowerShell connections only (not REST API connections), WinRM needs to allow Basic authentication. We don't send the username and password combination. The Basic authentication header is required to send the session's OAuth token, because the client-side implementation of WinRM doesn't support OAuth.
To verify that Basic authentication is enabled for WinRM, run the following command in a Command Prompt or Windows PowerShell:
Note
The following commands require that WinRM is enabled. To enable WinRM, run the following command: winrm quickconfig
.
winrm get winrm/config/client/auth
If you don't see the value Basic = true
, you need to run one of the following commands to enable Basic authentication for WinRM:
In a Command Prompt:
winrm set winrm/config/client/auth @{Basic="true"}
In Windows PowerShell:
winrm set winrm/config/client/auth '@{Basic="true"}'
In Windows PowerShell to modify the registry:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client' -Name 'AllowBasic' -Type DWord -Value '1'
If Basic authentication for WinRM is disabled, you'll get one of the following errors when you try to connect:
The WinRM client cannot process the request. Basic authentication is currently disabled in the client configuration. Change the client configuration and try the request again.
Create Powershell Session is failed using OAuth.
PowerShellGet for REST-based connections in Windows
REST-based connections in Windows require the PowerShellGet module, and by dependency, the PackageManagement module. Consideration for these modules is more for PowerShell 5.1 than PowerShell 7, but all version of PowerShell benefit from having the latest versions of the modules installed. For installation and update instructions, see Installing PowerShellGet on Windows.
Note
Beta versions of the PackageManagement or PowerShellGet modules might cause connection issues. If you have connection issues, verify that you don't have Beta versions of the modules installed by running the following command: Get-InstalledModule PackageManagement -AllVersions; Get-InstalledModule PowerShellGet -AllVersions
.
If you don't have PowerShellGet installed when you try to create a REST-based connection, you'll get the following error when you try to connect:
Cannot find a cmdlet Update-Manifest
Install the Exchange Online PowerShell module
To install the module for the first time, complete the following steps:
Install or update the PowerShellGet module as described in Installing PowerShellGet.
Close and re-open the Windows PowerShell window.
Now you can use the Install-Module cmdlet to install the module from the PowerShell Gallery. Typically, you'll want the latest public version of the module, but you can also install a Preview version if any are available.
To install the latest public version of the module, run one of the the following commands:
In an elevated PowerShell window (all users):
Install-Module -Name ExchangeOnlineManagement
Only for the current user account:
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser
To see the available Preview versions of the module, run the following command:
Find-Module ExchangeOnlineManagement -AllVersions -AllowPrerelease
To install the latest available Preview version of the module, run one of the following commands:
In an elevated PowerShell window (all users):
Install-Module -Name ExchangeOnlineManagement -AllowPrerelease
Only for the current user account:
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser -AllowPrerelease
To install a specific Preview version of the module, replace <PreviewVersion> with the necessary value, and run one of the following commands:
In an elevated PowerShell window (all users):
Install-Module -Name ExchangeOnlineManagement -RequiredVersion <PreviewVersion> -AllowPrerelease
Only for the current user account:
Install-Module -Name ExchangeOnlineManagement -RequiredVersion <PreviewVersion> -AllowPrerelease -Scope CurrentUser
When you're finished, enter Y to accept the license agreement.
For detailed syntax and parameter information, see Install-Module.
Update the Exchange Online PowerShell module
If the module is already installed on your computer, you can use the procedures in this section to update the module.
To see the version of the module that's currently installed and where it's installed, run the following command:
Get-InstalledModule ExchangeOnlineManagement | Format-List Name,Version,InstalledLocation
If the module is installed in C:\Program Files\WindowsPowerShell\Modules, it's installed for all users. If the module is installed in your Documents folder, it's installed only for the current user account.
You can use the Update-Module cmdlet to update the module from the PowerShell Gallery. Typically, you'll want the latest public version of the module, but you can also upgrade to a Preview version if any are available.
To upgrade to the latest public version of the module, run one of the following commands based on how you originally installed the module (all users vs. only for the current user account):
In an elevated PowerShell window (all users):
Update-Module -Name ExchangeOnlineManagement
Only for the current user account:
Update-Module -Name ExchangeOnlineManagement -Scope CurrentUser
To upgrade to a Preview version of the module, you can upgrade to the latest available Preview version, or you can use the RequiredVersion parameter to upgrade to a specific Preview version.
To see the available Preview versions of the module, run the following command:
Find-Module ExchangeOnlineManagement -AllVersions -AllowPrerelease
To upgrade to the latest available Preview version of the module, run one of the following commands:
In an elevated PowerShell window (all users):
Update-Module -Name ExchangeOnlineManagement -AllowPrerelease
Only for the current user account:
Update-Module -Name ExchangeOnlineManagement -Scope CurrentUser -AllowPrerelease
To upgrade to a specific Preview version of the module, replace <PreviewVersion> with the necessary value, and run one of the following commands:
In an elevated PowerShell window (all users):
Update-Module -Name ExchangeOnlineManagement -RequiredVersion <PreviewVersion> -AllowPrerelease
Only for the current user account:
Update-Module -Name ExchangeOnlineManagement -Scope CurrentUser -RequiredVersion <PreviewVersion> -AllowPrerelease
When you're finished, enter Y to accept the license agreement.
To confirm that the update was successful, run the following commands to check the version information of the module that's installed:
Import-Module ExchangeOnlineManagement; Get-Module ExchangeOnlineManagement
For detailed syntax and parameter information, see Update-Module.
Troubleshoot installing the Exchange Online PowerShell module
You receive one of the following errors:
The specified module 'ExchangeOnlineManagement' with PowerShellGetFormatVersion '<version>' isn't supported by the current version of PowerShellGet. Get the latest version of the PowerShellGet module to install this module, 'ExchangeOnlineManagement'.
WARNING: Unable to download from URI 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''.
WARNING: Unable to download the list of available providers. Check your internet connection.
Update your installation of the PowerShellGet module to the latest version as described in Installing PowerShellGet. Be sure to close and re-open the PowerShell window before you attempt to update the ExchangeOnlineManagement module again.
As of April 2020, the PowerShell Gallery only supports connections using TLS 1.2 or later. For more information, see PowerShell Gallery TLS Support.
To check your current settings in the Microsoft .NET Framework, run the following command in Windows PowerShell:
[Net.ServicePointManager]::SecurityProtocol
As described in the PowerShell Gallery TLS Support article, to temporarily change the security protocol to TLS 1.2 to install the PowerShellGet or ExchangeOnlineManagement modules, run the following command in Windows PowerShell before you install the module:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
To permanently enable strong cryptography in the Microsoft .NET Framework version 4.x or later, run one of the following commands based on your Windows architecture:
x64:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Type DWord -Value '1'
x86:
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Type DWord -Value '1'
For more information, see SchUseStrongCrypto.
You receive the following error:
No match was found for the specified search criteria and module name 'ExchangeOnlineManagement'. Try running
Get-PSRepository
to see all available registered module repositories.The default repository for PowerShell modules isn't set to PSGallery. To fix this error, run the following command:
Register-PSRepository -Default
Uninstall the Exchange Online PowerShell module
To see the version of the module that's currently installed and where it's installed, run the following command:
Get-InstalledModule ExchangeOnlineManagement | Format-List Name,Version,InstalledLocation
If the module is installed in C:\Program Files\WindowsPowerShell\Modules, it was installed for all users. If the module is installed in your Documents folder, it was installed only for the current user account.
To uninstall the module, run the following command in one of the following environments based on how you originally installed the module (all users vs. only for the current user account):
In an elevated PowerShell window (all users).
In a normal PowerShell window (only for the current user account).
Uninstall-Module -Name ExchangeOnlineManagement
For detailed syntax and parameter information, see Uninstall-Module.
Properties and property sets in the Exchange Online PowerShell module
Traditional Exchange Online cmdlets return all possible object properties in their output, including many properties that are often blank or aren't interesting in many scenarios. This behavior causes degraded performance (more server computation and added network load). You rarely (if ever) need the full complement of properties in the cmdlet output.
The Get-EXO* cmdlets in the module have categorized output properties. Instead of giving all properties equal importance and returning them in all scenarios, we've categorized specific related properties into property sets. Simply put, these property sets are buckets of two or more related properties on the cmdlet.
The biggest and most used Get-EXO* cmdlets use property sets:
In those cmdlets, property sets are controlled by the following parameters:
- PropertySets: This parameter accepts one or more available property set names separated by commas. The available property sets are described in Property sets in Exchange Online PowerShell module cmdlets.
- Properties: This parameter accepts one or more property names separated by commas.
You can use the PropertySets and Properties parameters together in the same command.
We've also included a Minimum property set that includes a bare minimum set of required properties for the cmdlet output (for example, identity properties). The properties in the Minimum property sets are also described in Property sets in Exchange Online PowerShell module cmdlets.
- If you don't use the PropertySets or Properties parameters, you automatically get the properties in the Minimum property set.
- If you use the PropertySets or Properties parameters, you get the specified properties and the properties in the Minimum property set.
Either way, the cmdlet output contains far fewer properties, and the time it takes to return those results is much faster.
For example, after you connect to Exchange Online PowerShell, the following example returns only the properties in the Minimum property set for the first ten mailboxes.
Get-EXOMailbox -ResultSize 10
In contrast, the output of the same Get-Mailbox command would return at least 230 properties for each of the first ten mailboxes.
Note
Although the PropertySets parameter accepts the value All, we highly discourage using this value to retrieve all properties, because it slows down the command and reduces reliability. Always use the PropertySets and Properties parameters to retrieve the minimum number of properties that are required for your scenario.
For more information about filtering in the module, see Filters in the Exchange Online PowerShell module.
Release notes
Unless otherwise noted, the current release of the Exchange Online PowerShell module contains all features of previous releases.
Current release
Version 3.3.0
- SkipLoadingCmdletHelp parameter on Connect-ExchangeOnline to support skip loading cmdlet help files.
- Global variable
EXO_LastExecutionStatus
is available to check the status of the last cmdlet that was run. - Bug fixes in Connect-ExchangeOnline and Connect-IPPSSession.
- IsUserControlEnabled parameter on Add-VivaModuleFeaturePolicy and Update-VivaModuleFeaturePolicy to support the enablement of user controls by policy for features that are onboarded to Viva feature access management.
Previous releases
Version 3.2.0
- New cmdlets:
- Get-DefaultTenantBriefingConfig and Set-DefaultTenantBriefingConfig.
- Get-DefaultTenantMyAnalyticsFeatureConfig and Set-DefaultTenantMyAnalyticsFeatureConfig.
- Get-VivaModuleFeature, Get-VivaModuleFeatureEnablement, Add-VivaModuleFeaturePolicy, Get-VivaModuleFeaturePolicy, Remove-VivaModuleFeaturePolicy, and Update-VivaModuleFeaturePolicy.
- REST API connection support for Security & Compliance Center PowerShell.
- ConnectionId parameter on Get-ConnectionInformation and Disconnect-ExchangeOnline:
- Get connection information for specific REST API connections.
- Selective disconnect for REST API connections.
- SigningCertificate parameter on Connect-ExchangeOnline allows you to sign the format files (*.Format.ps1xml) or script module files (.psm1) in the temporary module that Connect-ExchangeOnline creates with a client certificate to use in all PowerShell execution policies.
- Bug fixes in Connect-ExchangeOnline.
Version 3.1.0
- AccessToken parameter available in Connect-ExchangeOnline.
- Bug fixes in Connect-ExchangeOnline and Get-ConnectionInformation.
- Bug fix in Connect-IPPSSession for connecting to Security & Compliance PowerShell using CertificateThumbprint.
Version 3.0.0 (Preview versions known as v2.0.6-PreviewX)
- Features already described in the REST API connections in the EXO V3 module section:
- Certificate based authentication for Security & Compliance PowerShell (version 2.0.6-Preview5 or later).
- The Get-ConnectionInformation cmdlet for REST-based connections (version 2.0.6-Preview7 or later).
- The SkipLoadingFormatData switch on the Connect-ExchangeOnline cmdlet for REST-based connections (version 2.0.6-Preview8 or later).
- The DelegatedOrganization parameter works in the Connect-IPPSSession cmdlet as long as you also use the AzureADAuthorizationEndpointUri parameter in the command.
- Certain cmdlets that used to prompt for confirmation in specific scenarios no longer do so. By default, the cmdlet runs to completion.
- The format of the error returned from failed cmdlet execution has been slightly modified. The exception now contains additional data (for example, the exception type), and the
FullyQualifiedErrorId
doesn't contain theFailureCategory
. The format of the error is subject to further modification.
Version 2.0.5
New Get-OwnerlessGroupPolicy and Set-OwnerlessGroupPolicy cmdlets to manage ownerless Microsoft 365 groups.
Note
Although the cmdlets are available in the module, the feature is only available to members of a Private Preview.
New Get-VivaInsightsSettings and Set-VivaInsightsSettings cmdlets to control user access to Headspace features in Viva Insights.
Version 2.0.4
PowerShell 7 is officially supported in Windows, Linux, and Apple macOS as described in the Prerequisites for the Exchange Online PowerShell module section in this article.
The module in PowerShell 7 supports browser-based single sign-on (SSO) and other sign in methods. For more information, see PowerShell 7 exclusive connection methods.
The Get-UserAnalyticsConfig and Set-UserAnalyticsConfig cmdlets have been replaced by the Get-MyAnalyticsConfig and Set-MyAnalyticsConfig.Additionally, you can configure access at feature level. For more information, see Configure MyAnalytics.
Real-time policy and security enforcement in all user based authentication. Continuous Access Evaluation (CAE) has been enabled in the module. Read more about CAE here.
The LastUserActionTime and LastInteractionTime properties are now available in the output of the Get-EXOMailboxStatistics cmdlet.
The interactive sign-in process now uses a more secure method to fetch access tokens using safe reply URLs.
Version 2.0.3
- General availability of certificate based authentication (CBA), which enables using modern authentication in unattended scripting or background automation scenarios. The available certificate storage locations are:
- Remote in the Azure Key Value (the Certificate) parameter. This option enhances security by fetching the certificate only at runtime.
- Local in the CurrentUser or LocalMachine certificate store (the CertificateThumbprint parameter).
- Local in an exported certificate file (the CertificateFilePath and CertificatePassword parameters). For more information, see the parameter descriptions in Connect-ExchangeOnline and App-only authentication for unattended scripts in the Exchange Online PowerShell module.
- Connect to Exchange Online PowerShell and Security & Compliance PowerShell simultaneously in a single PowerShell window.
- The new CommandName parameter allows you to specify and restrict the Exchange Online PowerShell cmdlets that are imported in a session. This option reduces the memory footprint for high usage PowerShell applications.
- Get-EXOMailboxFolderPermission now supports ExternalDirectoryObjectID in the Identity parameter.
- Optimized latency of the first V2 cmdlet call. Lab results show the first call latency has been reduced from 8 seconds to approximately 1 second. Actual results depend on the cmdlet result size and the tenant environment.
Version 1.0.1
- General Availability (GA) version of the EXO V2 module. It is stable and ready for use in production environments.
- Get-EXOMobileDeviceStatistics cmdlet now supports the Identity parameter.
- Improved reliability of session auto-reconnect in certain cases where a script was running for ~50 minutes and threw a "Cmdlet not found" error due to a bug in auto-reconnect logic.
- Fixed data-type issues of two commonly used "User" and "MailboxFolderUser" attributes for easy migration of scripts.
- Enhanced support for filters as it now supports four more operators: EndsWith, Contains, Not and NotLike support. Check Filters in the Exchange Online PowerShell module for attributes that aren't supported in filters.
Version 0.4578.0
- Added support for configuring the Briefing Email for your organization at the user level with Set-UserBriefingConfig and Get-UserBriefingConfig cmdlets.
- Support for session cleanup using Disconnect-ExchangeOnline cmdlet. This cmdlet is the V2 equivalent of
Get-PSSession | Remove-PSSession
. In addition to cleaning up session object and local files, it also removes the access token from cache, which is used for authenticating against V2 cmdlets. - You can now use
FolderId
as an identity parameter in Get-EXOMailboxFolderPermission. You can get theFolderId
value using Get-MailboxFolder. For example:Get-MailboxFolderPermission -Identity <UPN>:<Folder-Path>
Get-MailboxFolderPermission -Identity <UPN>:\<Folder-Id>
- Improved reliability of Get-EXOMailboxStatistics as certain request routing errors which led to failures have been resolved.
- Optimized memory usage when a session is created by re-using any existing module with a new session instead of creating a new one every time session is imported.
Version 0.4368.1
- Added support for Security & Compliance PowerShell cmdlets using the Connect-IPPSSession cmdlet.
- Hiding the announcement banner is available using the ShowBanner switch (
-ShowBanner:$false
). - Terminate cmdlet execution on client exception.
- Remote PowerShell contained various complex data types which were intentionally not supported in EXO cmdlets to improve performance. Differences in non-complex data types between remote PowerShell cmdlets and V2 cmdlets have been resolved to allow seamless migration of management scripts.
Version 0.3582.0
- Support for prefix during session creation:
- You can create only 1 session at a time that contains prefixed cmdlets.
- EXO V2 cmdlets aren't prefixed because they already have the prefix EXO, so don't use
EXO
as a prefix.
- Use EXO V2 cmdlets even if WinRM Basic Auth is disabled on client machine. Note that remote PowerShell cmdlets require WinRM Basic Auth, and they won't be available if it's disabled.
- Identity parameter for V2 cmdlets now supports Name and Alias as well. Note that using Alias or Name slows down the performance of V2 cmdlets, so we don't recommend using them.
- Fixed issue where the data type of attributes returned by V2 cmdlet was different from remote PowerShell cmdlets. We still have few attributes which have differing data types, and we plan to handle them in coming months.
- Fixed bug: Frequent sessions reconnects issue when Connect-ExchangeOnline was invoked with Credentials or UserPrincipalName
Version 0.3555.1
- Fixed a bug where piped cmdlets were failing with the following error due to an authentication issue:
Cannot invoke the pipeline because the runspace isn't in the Opened state. Current state of the runspace is 'Closed'.
Version 0.3527.4
- Updated Get-Help content.
- Fixed an issue in Get-Help where the Online parameter was redirecting to a non-existent page with error code 400.
Version 0.3527.3
- Added support for managing Exchange for a different tenant using delegation flow.
- Works in tandem with other PowerShell modules in a single PS window.
- Added support for positional parameters.
- Date Time field now supports client locale.
- Bug fix: PSCredential empty when passed during Connect-ExchangeOnline.
- Bug fix: Client module error when filter contained $null.
- Sessions created internal to EXO V2 Module now have names (naming pattern: ExchangeOnlineInternalSession_%SomeNumber%).
- Bug fix: Remote PowerShell cmdlets intermittently failing due to time the difference between token expiry and the PSSession going idle.
- Major security update.
- Bug fixes and enhancements.
Feedback
Submit and view feedback for