Connect to Exchange Online PowerShell with Basic authentication

Exchange Online PowerShell allows you to manage your Exchange Online settings from the command line. You use Windows PowerShell on your local computer to create a remote PowerShell session to Exchange Online. It's a simple three-step process where you enter your Microsoft 365 credentials, provide the required connection settings, and then import the Exchange Online cmdlets into your local Windows PowerShell session so that you can use them.


What do you need to know before you begin?

  • Estimated time to complete: 5 minutes

  • You can use the following versions of Windows:

    • Windows 10

    • Windows 8.1

    • Windows Server 2019

    • Windows Server 2016

    • Windows Server 2012 or Windows Server 2012 R2

    • Windows 7 Service Pack 1 (SP1)*

    • Windows Server 2008 R2 SP1*

    * This version of windows has reached end of support, and is now only supported when running in Azure virtual machines. To use this version of Windows, you need to install the Microsoft .NET Framework 4.5 or later and then an updated version of the Windows Management Framework: 3.0, 4.0, or 5.1 (only one). For more information, see Install the .NET Framework, Windows Management Framework 3.0, Windows Management Framework 4.0, and Windows Management Framework 5.1.

  • Windows 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 Windows PowerShell window (a Windows PowerShell window you open by selecting Run as administrator):

    Set-ExecutionPolicy RemoteSigned
  • WinRM needs to allow Basic authentication (it's enabled by default). We don't send the username and password combination, but the Basic authentication header is required to transport the session's OAuth token, since the client-side WinRM implementation has no support for OAuth.

    To verify that Basic authentication is enabled for WinRM, run this command in a Command Prompt:


    You must temporarily enable WinRM to run the following commands. You can enable it by running the command: winrm quickconfig.

    winrm get winrm/config/client/auth

    If you don't see the value Basic = true, you need to run this command to enable Basic authentication for WinRM:

    winrm set winrm/config/client/auth @{Basic="true"}

    If Basic authentication for WinRM is disabled, you'll get this error 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.


Having problems? Ask for help in the Exchange forums. Visit the forums at: Exchange Online, or Exchange Online Protection.

Connect to Exchange Online

  1. On your local computer, open Windows PowerShell and run the following command.

    $UserCredential = Get-Credential

    In the Windows PowerShell Credential Request dialog box, type your work or school account and password, and then click OK.

  2. Run the following command:

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $UserCredential -Authentication Basic -AllowRedirection


    • For Office 365 operated by 21Vianet, use the ConnectionUri value:

    • For Office 365 Germany, use the ConnectionUri value:

    • For Microsoft 365 GCC High, use the ConnectionUri value:

    • For Microsoft 365 DoD, use the ConnectionUri value:

    • If you're behind a proxy server, run this command first: $ProxyOptions = New-PSSessionOption -ProxyAccessType <Value>, where <Value> is IEConfig, WinHttpConfig, or AutoDetect.

      Then, add the following parameter and value to the end of the $Session = ... command: -SessionOption $ProxyOptions.

      For more information, see New-PSSessionOption.

  3. Run the following command:

    Import-PSSession $Session -DisableNameChecking


Be sure to disconnect the remote PowerShell session when you're finished. If you close the Windows PowerShell window without disconnecting the session, you could use up all the remote PowerShell sessions available to you, and you'll need to wait for the sessions to expire. To disconnect the remote PowerShell session, run the following command.

Remove-PSSession $Session

How do you know this worked?

After Step 3, the Exchange Online cmdlets are imported into your local Windows PowerShell session and tracked by a progress bar. If you don't receive any errors, you connected successfully. A quick test is to run an Exchange Online cmdlet, for example, Get-Mailbox, 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 user name and password you enter in Step 1.

  • To help prevent denial-of-service (DoS) attacks, you're limited to three open remote PowerShell connections to your Exchange Online organization.

  • The account you use to connect to Exchange Online must be enabled for remote PowerShell. For more information, see Enable or disable access to Exchange Online PowerShell.

  • 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.

  • If your organization uses federated authentication, and your identity provider (IDP) and/or security token service (STS) isn't publicly available, you can't use a federated account to connect to Exchange Online PowerShell. Instead, create and use a non-federated account in Microsoft 365 to connect to Exchange Online PowerShell.

See also

The cmdlets that you use in this topic are Windows PowerShell cmdlets. For more information about these cmdlets, see the following topics.

For more information about managing Microsoft 365, see Manage Microsoft 365 and Office 365.