Leave it to Microsoft to create short an sweet names for their products. This time though, it’s a real pearl – and we’ll just shorten the name to ExRCA for the rest of this article.
(Edit: If you have suggestions for new name, or other comments, visit the site and click the Feedback-link)
Currently this tool is marked with “Beta”, and I suspect Microsoft are taking after Google here, notorious for their eternal beta products.
ExRCA is a gem in and of it’s own, and supplies great insight for those of us that really need it – the Exchange Administrator/Architect/Implementer/Troubleshooter.
It’s merely a troubleshooting tool in the form of a webpage that will, provided you submit it some information, connect and analyze your externally exposed Exchange Web Services! At the time of writing, these are your options:
- Microsoft Exchange ActiveSync Connectivity Tests
- Exchange ActiveSync with AutoDiscover
- Exchange ActiveSync (which is the one I’ve tested so far)
- Microsoft Exchange Web Services Connectivity Tests
- ActiveSync Provider AutoDiscover
- Outlook Provider AutoDiscover
- Microsoft Office Outlook Connectivity Tests
- Outlook Anywhere with AutoDiscover
- Outlook 2003 RPC/HTTP
- Internet Email Tests
- Inbound SMTP Email Test
Are you still reading? I’ll give you the link to this site in a moment, let me just give you some background on the issue I was facing first:
I was recently tasked with setting up external services like Outlook Web Access and Exchange Active Sync for mobile devices for a client. The Exchange Server in question was one typical non-dedicated server – loaded with other services. There were several services installed in the “Default Web Site” in IIS, all of which had imposed *their* settings into IIS. The Exchange web services hadn’t been in use before, but my client desired a move into the future, and so they wanted to utilize email, calendar, contact and task synchronization to their various mobile devices.
The web services are automatically installed and set up by Exchange when you first install it, but since the other services had had their way with the IIS site, “nothing” was working – no SSL, no permissions, no configurations – seemed to be in order for Exchange web services.
As I started ironing out the creases, more and more functionality came in to place and to make a long story short, I had only one thing remaining that didn’t work properly, and that was the most important – device synchronization with ActiveSync!
I had already configured the service and was able to connect, providing a user name and password, but when it came time to move data, the device (an old HTC S710 I keep around just for testing) would throw an error message (It was “Support Code 0x85010014” if you’re interested) that I couldn’t quite get my head around, because every search for this code gave me different results.
In the end I stumbled upon a forum thread that seemed to be moving into the same problem I was having. A moderator suggested they go to the Microsoft Exchange Remote Connectivity Analyzer and use it to analyze the problem.
I did the same, and using a test user-ID (as recommended – do no use any production user-ID unless you absolutely have to) I ran the test. My client didn’t have a trusted SSL certificate installed on his IIS Server at the time, so I had to check “Ignore Trust for SSL” to make the tests pass.
After supplying the server name and user credentials and verifying to the service that I understood what this was going to do, the tests ran and a report was presented in the webpage. It informed me that connecting and communicating was working fine, but there was something towards the end that failed. It then supplied a link to a Technet article explaining what was wrong and a link to a KB Article on how to fix the issue. I needed to create a separate Virtual Directory for non-SSL Outlook Mobile Access, and once I had that I redirected clients to it using a registry key.
The information gathered by ExRCA was invaluable in resolving the issue, and will definitely be a part of my toolbox from now on!