Welcome to Exchange Team Blog Sign in | Join | Help

Syndication

This Blog

New version of Exchange Remote Connectivity Analyzer has been released

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.

Published Monday, October 19, 2009 8:46 AM by Exchange
Filed Under: , , , , , , ,

Comments

 

Scott Pauls said:

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?
October 19, 2009 12:13 PM
 

Scott said:

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!
October 19, 2009 4:20 PM
 

Chris Lehr said:

Great article, and thanks as always for all the support!

Chris

pingback from:
http://chrislehr.com/2009/10/exchange-remote-connectivity-analyzer.htm
October 19, 2009 6:37 PM
 

Sejong said:

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?
October 20, 2009 8:53 AM
 

J_Oz said:

Love the video, it's hilarious!   My dad is an exchange administrator....haa  
October 20, 2009 9:36 AM
 

Brad Hughes [MSFT] said:

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
October 20, 2009 11:37 AM
 

sjustq said:

Each Time I get here I learned Somthing New (Fabulous Guys)
December 1, 2009 12:35 PM
 

Christian Aguilera said:

Thanks Chris, fun video, great news!!

pingback from mi spanish blog: http://christian-aguilera.spaces.live.com/blog/cns!5E5045141DC03BB1!2024.entry

December 10, 2009 8:26 AM
New Comments to this post are disabled

News


This blog and its contents are provided "AS IS" with no warranties, and they confer no rights. Use of any included script samples are subject to the terms specified in the Terms of Use.
New! Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.

Exchange Server 2010 - Get the Release Candidate



Poll:

Other Exchange Blogs from MSFT