Home » Exchange Server » Exchange Server 2013: Using Test-OutlookWebServices to Verify Web Services Functionality

Exchange Server 2013: Using Test-OutlookWebServices to Verify Web Services Functionality

The Test-OutlookWebServices PowerShell cmdlet allows you to test the functionality of the following services:

  • Autodiscover
  • Exchange Web Services
  • Availability Service
  • Offline Address Book

Running the cmdlet on a Client Access server will test the local server using the test mailbox user created earlier.

You can also perform the test for a specific mailbox by using the –Identity and –MailboxCredential parameters.

Tip: Testing a specific mailbox is useful if you are troubleshooting problems with one or more of the Outlook Web Services in a particular site within your organization. You can compare results between test mailboxes in different sites to help you narrow down the source of any problems you’re seeing.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Chandezon says:

    Hello Paul,
    and congratulation for your work on this website!
    Have you test this cmdlet on an environement with separed roles?
    If I test with one of my CAS Servers, I’ve an error message “The specified server, CAS-Server, isn’t a Client Access server”.

    If I test with one of my Mailbox servers, this command is executed. (The autodiscover scenario result is failure, normal..)

  2. BerndL says:

    Hello Paul,
    are you sure this command runs still in Exchange 2013, in my case it is Ex2013 SP1. I get always the error missing user or user mailbox.
    I´ve heard that several test commands are used by the managed availability and so you can not use them anymore directly.
    Do you know which test commands are still working in Exchange 2013 and which not?

  3. Milinko says:

    Hi Paul,

    I’m having issue with autodiscovery on new exchange 2013. I’ve ran

    Get-ClientAccessServer | Test-OutlookWebServices -Identity username@domainname.com -MailboxCredential (Get-Credential)

    and result is that all three services failed. None of the domain connected workstations and outlook 2013 installed on them can connect to the exchange failing with error The attampt to log on to Microsft Exchange failed.

    Please advise!

    • Autodiscover problems have several common causes:

      1) The Autodiscover URI has not been configured/changed from the default
      2) The Autodiscover URI can’t be resolved in DNS
      3) The Exchange server’s SSL certificate does not include the Autodiscover URI
      4) The Autodiscover SCP does not exist

      Which of those can you say you’ve already checked out?

      • Mike says:

        Hi Paul,

        Have the same issue when running the command.

        User’s internally are also disconnected from Exchange (once a day) and forced to reboot to re-establish a connection (work offline/online doesn’t help).
        In addition, disabling cached connections makes no difference, as they’ll eventually get dropped too.

        Test-Outlookwebservices returns success results on all four scenarios, but with high latency (sometimes in excess of 500ms-1s).

        Running the same command including a user account via Get-ClientAccessServer command results in all scenario’s failing, with the Service Endpoint reflected as the internal FQDN rather than the autodiscover URI as configured (as shows up when running ‘Test-OutlookWebservices’.

        What the heck am I missing?
        Included below are (mildly modified for privacy) logs (Server name & External endpoint renamed but kept consistent with results). We are using a WildCard Cert on the server.

        We are running multiple accepted domains, so we have clientdomain1.com, clientdomain2.com as accepted, and our wildcard certificate setup as a 3rd unrelated domain.
        I have setup forward lookup zones for the 3rd domain to resolve to the mail server internally.

        [PS] D:exchange>Test-OutlookWebServices

        Source ServiceEndpoint Scenario Result Latency
        —— ————— ——– —— ——-
        Exch.EL.local mail.elsetup.ca Autodiscover: Outlook Provider Success 488
        Exch.EL.local mail.elsetup.ca Exchange Web Services Success 152
        Exch.EL.local mail.elsetup.ca Availability Service Success 1016
        Exch.EL.local mail.elsetup.ca Offline Address Book Success 120

        [PS] D:exchange>Get-ClientAccessServer | Test-OutlookWebServices -Identity administrator@clientdomain.com -MailboxCr
        edential (Get-Credential)

        Source ServiceEndpoint Scenario Result Latency
        —— ————— ——– —— ——-
        Exch.El.local exch.el.local Autodiscover: Outlook Provider Failure 51
        Exch.El.local exch.el.local Exchange Web Services Failure 3
        Exch.El.local Availability Service Skipped 0
        Exch.El.local exch.el.local Offline Address Book Failure 50

        Autodiscover problems have several common causes:

        1) The Autodiscover URI has not been configured/changed from the default
        Has been set as https://mail.elsetup.ca/autodiscover/autodiscover.xml
        2) The Autodiscover URI can’t be resolved in DNS
        mail.elsetup.ca resolves internally to the Exchange Server
        3) The Exchange server’s SSL certificate does not include the Autodiscover URI
        Its a wildcard cert – *.elsetup.ca
        4) The Autodiscover SCP does not exist
        It does exist, and matches the autodiscover URI

        What am I missing?
        We are running Exch2013 SP1, so MAPI is enabled, and clients are running Outlook 2013 Sp1.

        Any insight would be greatly appreciated!

  4. Milinko says:

    Weird thing is that from exchange server itself outlook connects without problem using autodiscovery to any user mailbox but if I try to do it from any of the domain connected workstations running outlook fails with error that outlook needs to be connected.

    1: Autodiscover URI is https:// FQDN/Autodiscover/Autodiscovery.xml

    when connected to that url I get prompted, fill in the user name/pass and will get 600 ErrorCode which means that the thing is working. I guess.

    2. All of the workstation running outlook are on internal network and are part of the domain. They should get their autodiscover through AD. or not? I dont have autodiscover DNS pointing to internal mail server.

    3. Exchange server SSL is the default one that was installed while setting up the Exchange. in Subject Alternative Name I have just server name and FQDN of the server.

    4. When I run Get-AccessClientServer I do get hostname of the server and when I run Get-ClientAccesServer | fl I do get FQDN of the server, OutlookAnywhereEnabled true, AutoDiscoverCN = hostname, ms-Exchange-AutoDiscover-Service, that url from answer 1 and IsOutOfService is set to False.

    OWA is working properly, ActiveSync is working good as well and I can login into admin without problem. Really weird.

    Thank you for taking time to help me!

  5. Milinko says:

    Last Update. After installing certificate from trusted CA Authority everything is back to normal.

    Thank you for very much your help!

    btw! I’m buying your book as well 🙂

  6. Martin says:

    Hi Paul,

    My outlook clients fail to connect to my Exchange2013. It keeps prompting for username and password and i cannot create a new profile. “The connection to Microsoft Exchange is unavailable. Is the error i get.

  7. Ben says:

    Hello Paul,

    I noticed first off that by default these won’t run if you have the word “User” anywhere in your domain. Basically, the script to create the user fails. Running it manually fails as well. This worked for me, http://www.definit.co.uk/tag/new-testcasconnectivityuser-ps1/

    In addition, the test on the specific mailbox is telling me that my client access servers are not client access servers? I’m chalking this up to more buggy crap with MS. Just wanted to pass it along.


  8. Jameel says:

    Hi Paul,

    Please help….

    Exchange 2013

    1) The Autodiscover URI has not been configured/changed from the default
    – configured as… -AutoDiscoverServiceInternalURI https://mail.mydomain.com/Autodiscover/Autodiscover.xml

    2) The Autodiscover URI can’t be resolved in DNS
    – it can be resolved…. https://mail.mydomain.com/Autodiscover/Autodiscover.xml

    3) The Exchange server’s SSL certificate does not include the Autodiscover URI
    – has the ssl cert (SAN) from Comodo.for mail.mydomain.com

    4) The Autodiscover SCP does not exist
    -serviceBindingInformation = https://mail.mydomain.com/Autodiscover/Autodiscover.xml
    -keywords = our site (AD Site), also has a long number

    When I run Test-OutlookWebServices,…. I get Autodiscover: Outlook Provider Failure
    Can’t download OAB from Outlook 2013. Also, can’t do Out of Off, No calendar free/busy while scheduling.

    FYI, Arbitration mailbox is in server mbx01, but when I run Test-OutlookWebServices, the Source server is mbx03. Don’t know if that has to do anything with it.

  9. Jameel says:

    Please disregard my previous comment. It is working now. The issue was, I didn’t remove the redirection from the ECP virtual directory.


  10. Simon says:

    I get the following error when running test-outlookweb services command on Windows server 2012 r2 hosting exchange 2013 cu 11 hosting combined cas and mailbox roles . I’m using a SAN cert which checks out ok when browsing to OWA.
    Have been stuck on this error for last 5 days . Cert has been exported from a exchange 2010 server . When I use command with -trustanysslcertificate I get a successful result . SAN cert provided by quovadis . Have you come across this error before ?
    RunspaceId : 77c04e1c-6e4e-4ba8-90b1-54188443c274
    Source : EX13MB1.domain.com
    ServiceEndpoint : ex13mb1.domain.com
    Scenario : AutoDiscoverOutlookProvider
    ScenarioDescription : Autodiscover: Outlook Provider
    Result : Failure
    Latency : 1
    Error : System.Net.WebException: The underlying connection was closed: Could not establish trust
    relationship for the SSL/TLS secure channel. —>
    System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

Leave a Reply

Your email address will not be published. Required fields are marked *