If you’ve followed the past couple of articles you’ll no doubt have noticed I haven’t gone out of my way to handle exceptions and errors gracefully. If you run into a problem when running the sample code against an Exchange that for some reason is configured differently than mine, (also known as entirely wrong by definition), you might run into the very helpful “Something happened” message without further explanation.

One might be tempted to ask if it’s because I’m lazy, or simply do not know how to handle it. Well, ask no more, because I now intend to do something about it
(..)
Listing two methods for handling exceptions and errors

Background reading (not a pre-requisite):
[MS-ASHTTP] – ActiveSync HTTP Protocol – OPTIONS
[MS-ASCMD] – ActiveSync Command Reference – FolderSync
Digging Into The Exchange ActiveSync Protocol

If you followed along with the Autodiscover coding session you have now passed the initial hurdle of locating an ActiveSync-enabled Exchange Server. So how about we try to make a connection with that server and fetch some information from it?

There are three steps you can take in this process, where the last one will also establish a synchronization partnership with Exchange:
– HTTP GET
– HTTP OPTIONS
– HTTP POST

Yes, that’s a very generic description, so let’s describe them further.
(…)

Background reading (not a pre-requisite):
EAS MD 1.4 – Autodiscover Support
blogs.msdn.com – Autodiscover for ActiveSync Developers
[MS-ASCMD] -ActiveSync Command Reference – Autodiscover

So, enough with the excuses. Give us something we can compile, that we can use in an actual ActiveSync client, that is relevant – just something already.

Where to start with a topic like the Exchange ActiveSync protocol? I decided that although it’s kind of in reverse order if you use my EAS MD utility as the yardstick, I wanted to cover the last feature I implemented first in this series (Hey, that means I might still have the code fresh in mind, right?)

There is a reason I do it in this order. When building my tool Autodiscover wasn’t initially on top of the list of issues I had when testing and verifying Exchange Server ActiveSync setups. (I think figuring out the provisioning process was on top of my list actually.)
But at the same time – when you configure an ActiveSync client one of the first things you have to be aware is the address to your Exchange Server. While this is not a big problem to solve by manually typing in the address it does feel smoother just typing your email address accompanied by your password and have the device figure out the rest of it. And while most IT pros will be able to figure out the address to the Exchange Server, (unless your Exchange admin is refusing to let you in on it), many end-users have no idea what Exchange even means. They usually have a clue as to what their email address might be though, so that might be a good starting point on their quest to get mail and “stuff” on their devices.

As it turns out it’s also one of the easier parts of the protocol to get started with, as you don’t have to concern yourself with WBXML and such. I’ve previously explained how Autodiscover works in general, so read up on that if you’re a bit unsure as to what we’re talking about here. (Link on top of this post.)
(…)
Getting down to real coding – implementing the Autodiscover tests.