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.
Hi Paul
This command is valid also for Exchange 2016?
Thanks
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.
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
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?
Please disregard my previous comment. It is working now. The issue was, I didn’t remove the redirection from the ECP virtual directory.
Thanks..
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.
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
More buggy crap? Ok.
Well anyway, the OU issue is easily worked around by adding the -OU switch when running the script, as I mentioned here:
https://www.practical365.com/exchange-server-2013-creating-a-test-mailbox-user-for-troubleshooting-with-test-cmdlets/
“If necessary use the –OU parameter to specify which OU the account should be created in.”
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.
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 🙂
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!
It isn’t weird that Outlook works fine on the Exchange server itself, because it trusts its own self-signed SSL certificate.
Which brings me to your point #3 – if you’re using the default, self-signed SSL certificate then that will not work.
Some reading:
https://www.practical365.com/exchange-server-2013-ssl-certificates/
And:
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
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!
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?
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!
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?
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?
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
Yeah, several of these test cmdlets don’t work the same for standalone CAS.