This article contains instructions for how to connect to Security & Compliance PowerShell using the Exchange Online PowerShell module with or without multi-factor authentication (MFA).
The Exchange Online PowerShell module uses modern authentication 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 more information about the Exchange Online PowerShell module, see About the Exchange Online PowerShell module.
Step 1: Load the Exchange Online PowerShell module
Note
If the module is already installed, you can typically skip this step and run Connect-IPPSSession without manually loading the module first.
After you've installed the module, open a PowerShell window and load the module by running the following command:
PowerShell
Import-Module ExchangeOnlineManagement
Step 2: Connect and authenticate
Note
Connect commands will likely fail if the profile path of the account that you used to connect contains special PowerShell characters (for example, $). The workaround is to connect using a different account that doesn't have special characters in the profile path.
The command that you need to run uses the following syntax:
<UPN> is your account in user principal name format (for example, navin@contoso.onmicrosoft.com).
The required ConnectionUri and AzureADAuthorizationEndpointUri values depend on the nature of your Microsoft 365 organization. Common values are described in the following list:
Microsoft 365 or Microsoft 365 GCC:
ConnectionUri: None. The required value https://ps.compliance.protection.outlook.com/powershell-liveid/ is also the default value, so you don't need to use the ConnectionUri parameter in Microsoft 365 or Microsoft 365 GCC environments.
AzureADAuthorizationEndpointUri: None. The required value https://login.microsoftonline.com/common is also the default value, so you don't need to use the AzureADAuthorizationEndpointUri parameter in Microsoft 365 or Microsoft 365 GCC environments.
If you're behind a proxy server, you can use the PSSessionOption parameter in the connection command. First, run this command: $ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>, where <Value> is IEConfig, WinHttpConfig, or AutoDetect. Then, use the value $ProxyOptions for the PSSessionOption parameter. For more information, see New-PSSessionOption.
Depending on the nature of your organization, you might be able to omit the UserPrincipalName parameter in the next step. Instead, you enter the username and password or select stored credentials after you run the Connect-IPPSSession command. If it doesn't work, then you need to use the UserPrincipalName parameter.
If you aren't using MFA, you should be able to use the Credential parameter instead of the UserPrincipalName parameter. First, run the command $Credential = Get-Credential, enter your username and password, and then use the variable name for the Credential parameter (-Credential $Credential). If it doesn't work, then you need to use the UserPrincipalName parameter.
Connect to Security & Compliance PowerShell with an interactive login prompt
The following examples work in Windows PowerShell 5.1 and PowerShell 7 for accounts with or without MFA:
This example connects to Security & Compliance PowerShell in a Microsoft 365 or Microsoft 365 GCC organization:
In the sign-in window that opens, enter your password, and then click Sign in.
Note
In PowerShell 7, browser-based single sign-on (SSO) is used by default, so the sign in prompt opens in your default web browser instead of a standalone dialog.
MFA only: A verification code is generated and delivered based on the response option that's configured for your account (for example, a text message or the Microsoft Authenticator app on your device).
In the verification window that opens, enter the verification code, and then click Verify.
Connect to Security & Compliance PowerShell without a login prompt (unattended scripts)
Be sure to disconnect the session when you're finished. If you close the PowerShell window without disconnecting the session, you could use up all the sessions available to you, and you need to wait for the sessions to expire. To disconnect the session, run the following command:
PowerShell
Disconnect-ExchangeOnline
To silently disconnect without a confirmation prompt, run the following command:
PowerShell
Disconnect-ExchangeOnline -Confirm:$false
Note
The disconnect command will likely fail if the profile path of the account that you used to connect contains special PowerShell characters (for example, $). The workaround is to connect using a different account that doesn't have special characters in the profile path.
How do you know you've connected successfully?
The Security & Compliance PowerShell cmdlets are imported into your local Windows PowerShell session and tracked by a progress bar. If you don't receive any errors, you've connected successfully. A quick test is to run a Security & Compliance PowerShell cmdlet, for example, Get-RetentionCompliancePolicy, and see the results.
If you receive errors, check the following requirements:
A common problem is an incorrect password. Run the three steps again and pay close attention to the username and password that you use.
TCP port 80 traffic needs to be open between your local computer and Microsoft 365. It's probably open, but it's something to consider if your organization has a restrictive internet access policy.
REST-based connections to Security & Compliance PowerShell require the PowerShellGet module, and by dependency, the PackageManagement module, so you'll receive errors if you try to connect without having them installed. For example, you might see the following error:
The term 'Update-ModuleManifest' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
You might fail to connect if your client IP address changes during the connection request. This can happen if your organization uses a source network address translation (SNAT) pool that contains multiple IP addresses. The connection error looks like this:
The request for the Windows Remote Shell with ShellId <ID> failed because the shell was not found on the server. Possible causes are: the specified ShellId is incorrect or the shell no longer exists on the server. Provide the correct ShellId or create a new shell and retry the operation.
To fix the issue, use an SNAT pool that contains a single IP address, or force the use of a specific IP address for connections to the Security & Compliance PowerShell endpoint.
Provides a resolution for an issue in which you can't connect to Security & Compliance PowerShell when you use the Connect-IPPSSession PowerShell cmdlet.
