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.

[PS] C:>Test-OutlookWebServices

Source                                         Scenario  Result
------                                         --------  ------
E15MB1.exchange2013demo.com AutoDiscoverOutlookProvider Success
E15MB1.exchange2013demo.com         ExchangeWebServices Success
E15MB1.exchange2013demo.com         AvailabilityService Success
E15MB1.exchange2013demo.com          OfflineAddressBook Success

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

[PS] C:>Get-ClientAccessServer | Test-OutlookWebServices -Identity paul.cunningham@exchange2013demo.com -MailboxCredential (Get-Credential)

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.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. JackP

    Hi Paul

    This command is valid also for Exchange 2016?

    Thanks

  2. Simon

    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.

  3. Wajeeh

    hello paul,

    running below:
    [PS] C:\>Get-ClientAccessServer | Test-OutlookWebServices -Identity abc@exch-2013.sv.local -MailboxCredential (Get-Credentialjohn8)

    I get below message
    Source ServiceEndpoint Scenario Result
    Exch-2013.sv.local Exch-2010.sv.local Autodiscover:outlook provider failure

    rest are skipped, above I ran on exch-2013

    if I test Test-OutlookWebServices result is same as above

    Can you please help why ServiceEndpoint still showing 2010 while user mailbox is moved to 2013 and this is even for any new mailbox directly created on 2013, outlook unable to set his account either automatically/manually

  4. Thomas

    Hi.

    I have a problem with Exchange and Outlook. I can’t connect Outlook to Exchange.

    When I use Microsoft Remote Connectivity Analyzer I have errors(SSL error have becouse I don’t buy certificate yet):

    Od zdalnego serwera Unknown otrzymano odpowiedź HTTP 401 Brak autoryzacji. Jest to zazwyczaj wynik użycia nieprawidłowej nazwy użytkownika lub hasła. Jeśli próbujesz zalogować się do usługi Office 365, upewnij się, że używasz pełnej głównej nazwy użytkownika (UPN).
    Nagłówki odpowiedzi HTTP:
    request-id: 97c5ad44-4e2b-4cc4-94bf-8367602a9d30
    X-SOAP-Enabled: True
    X-WSSecurity-Enabled: True
    X-WSSecurity-For: None
    X-OAuth-Enabled: True
    Cache-Control: private
    Server: Microsoft-IIS/8.5
    WWW-Authenticate: Negotiate,NTLM,Basic realm=”autodiscover rivait eu”
    X-AspNet-Version: 4.0.30319
    X-Powered-By: ASP.NET
    X-FEServer: RIVAITWADOWICE
    Date: Mon, 10 Nov 2014 12:07:20 GMT
    Content-Length: 0
    Upłynęło czasu: 321 ms.

    When I use command Test-OutlookWebServices I get this errors:

    Autodiscover: Outlook Provider Failure 4854
    Exchange Web Services Failure 62
    Availability Service Skipped 0
    Offline Address Book Skipped 0

    How to fix this errors?

  5. Jameel

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

    Thanks..

  6. Jameel

    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.

  7. Ben

    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.

    Thanks

  8. Martin

    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.

  9. Milinko

    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 🙂

  10. Milinko

    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!

      1. Milinko

        Thank you for the info.

        I’m in process getting trusted certificates but what is strange is when I execute command

        Get-ClientAccessServer | Select Name,AutoDiscoverServiceInternalURI

        it comes up empty. It also comes up empty when I execute command

        Get-ClientAccessServer | Select Server,ExternalURL, InternalURL | fl

        but when I execute

        GetClientAccessServer | fl AutoDiscoverServiceInternalURI

        it returns the proper autodiscover url with FQDN.

        Thank you!

  11. Milinko

    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!

    1. Paul Cunningham

      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?

      1. Mike

        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
        (MS)
        —— ————— ——– —— ——-
        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
        (MS)
        —— ————— ——– —— ——-
        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!

  12. BerndL

    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?

    1. Paul Cunningham

      You’re seeing a warning or error that there is no CAS test user? Have you run the new-TestCasConnectivityUser.ps1 script to create one?

  13. Chandezon

    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..)
    Thanks

    1. Paul Cunningham

      Yeah, several of these test cmdlets don’t work the same for standalone CAS.

Leave a Reply