Blog Post

Exchange Team Blog
2 MIN READ

New version of Exchange Remote Connectivity Analyzer has been released

The_Exchange_Team's avatar
Oct 19, 2009

Today we released an updated version of the Exchange Remote Connectivity Analyzer. For those of you not familiar with this site, it is a Web-based tool that helps you troubleshoot connectivity issues. The tool simulates several client logon and mail flow scenarios. When a test fails, many of the errors have troubleshooting tips to assist you in correcting the problem. For more information, see our previous blog post here.

New/updated features

  • Updated user interface
  • New CAPTCHA implementation. (This is the hard to read words that make you prove you are a human)
  • No more 'Beta' label
  • Additional tests
    • Exchange Web Services - This allows you to perform connectivity testing for Exchange Web Services client such as Entourage. Developers can also use the Service Account Verification test to ensure things are configured and working properly for access with an alternate account or ExchangeImpersonation.
    • Outbound SMTP - Performs Reverse DNS testing, DNS RBL Checks, and SenderID validation against a provided "outbound" IP address
  • Updated the Outlook Anywhere test logic to work with Exchange 2010
  • Added a link in the footer to the Remote Connectivity Analyzer TechNet forum
  • Added a password confirmation text box to ensure the proper password was entered before running a test. This will reduce the number of tests that fail simply due to a typo in the password.

Known Issues

  • The Exchange ActiveSync tests allow you to "Ignore trusts for SSL". Checking this option only tells the tool to not fail if the certificate you are using is not in the list of Trusted Root Certificates... for example if you were using a certificate from your own Windows CA. This option does not allow the test to be completed over a non-SSL connection. That is, if you do not have a certificate and want to test whether Exchange ActiveSync works over port 80 - this tool cannot perform this validation. (Note: We will not be able to add this feature in the future). Note: Due to limitations in the RPC API, we are currently unable to ignore the trust requirement for SSL for the RPC over HTTP / Outlook Anywhere tests. We are looking into alternatives for future releases.

Thank you to everyone who sent feedback to us. The above list is a direct result of the comments you provided. Please keep the feedback coming. We also like to hear when the tool helps make you successful. The "Feedback" link is in the footer of each page on the site. This goes directly to Brad and me.

Link to tool: https://www.TestExchangeConnectivity.com

Here's a little video I created about the tool:

Enjoy!

- Shawn McGrath & Brad Hughes.

Updated Jul 01, 2019
Version 2.0
  • That is kewl. I have used that and it is helpful at times. The big question is when can we get our hands on the RTM version of Exchange 2010?
  • Thanks, this is a great tool and I'm glad to see it out there and a continuing effort to improve it.

    Also, Loved the video.  Enjoy your tea time!
  • When I run the Outlook Autodiscover test from ExRCA, it looks for a certificate whose subject is domainname.com.  When I run Test-OutlookWebServices from the Exchange Management Shell, it looks for a certificate whose subject is servername.domainname.com.  The same certificate won't work for both tests, so one test fails.  Is this expected behavior?
  • Love the video, it's hilarious!   My dad is an exchange administrator....haa  
  • Hey Sejong,


    Part of the Autodiscover process will try to connect to

    https://domain.com/autodiscover/autodiscover.xml, but many times this is *expected* to fail with a cert name mismatch - the Outlook client also moves past this.  Typical deployments are with a wildcard or UC certificate with multiple names on the certificate.

     So you'd probably have: autodiscover.domain.com and mail.domain.com on the certificate.  Test-OutlookWebServices is just using the InternalUrl or ExternalUrl values provided from the WebServicesVirtualDirectory.  You can run "Get-WebServicesVirtualDirectory

    | fl *url" in the Management Shell to view these values.  These also can be changed via Set-WebServicesVirtualDirectory.  You should probably check out the Autodiscover Whitepaper or post in the appropriate TechNet forum for more info.



    Brad

  • Each Time I get here I learned Somthing New (Fabulous Guys)