EAS-MD Version 1.4 – Autodiscover Support

This time around it was a long release cycle, but I have gotten around to finishing up a new build of the EAS-MD utility and upping the version number to 1.4.

The main addition to this release is that I’ve added support for testing Autodiscover. This can be a tricky point getting to work properly so I thought it could be relevant for of you. This means I’ve also added support in general for redirection and reading it out if you’re hitting a non-optimal Client Access Server. (The modus operandi for Office 365 is apparently that you should configure your device with m.outlook.com and then be redirected to a specific CAS. They might have changed this by now since Android devices have a couple of problems with this approach – I do not know since I haven’t tested the ActiveSync part of Office 365 yet.)

There are a couple of other changes as well:
– Added Client Certificate Password text box (for pfx-files).
– Added ActiveSync Autodiscover tests. (Please note that SRV record support is not added yet, and thus disabled in the UI.)
– Added scrollbars to output windows.
– Added possibility to use both domain\user and user@domain.com (leave “Domain” textbox empty to use the latter).
– Added support for parsing out the redirect on a HTTP 451.
– Added handling of HTTP 302.
– Added explanation for HTTP 502.
– Added explanation for HTTP 504.
– Disabled “Hex” view option on Main tab. (Code still present, but not sure if this is actually useful, so it’s not active in the UI.)
– Re-designed how HTTP status codes are shown in the output view. (Parses out the individual HTTP codes for errors.)
– Changed default protocol version to 12.1 (Exchange 2007 SPx).
– Major code refactoring.
– Fixed minor bugs.
– Minor changes in the UI.
– Added about tab. (Easier to identify the version you’re running.)

Looks like this:
image

The workings of Autodiscover
Since I added a new feature I feel obliged to explain it in a couple of words too. Now, the Exchange API-spotting blog at MSDN actually has a couple of worthwhile paragraphs on this already:
http://blogs.msdn.com/b/exchangedev/archive/2011/07/08/autodiscover-for-exchange-activesync-developers.aspx

So I won’t repeat that, but I’ll add a couple of observations you should be aware of.

With Exchange 2007 and 2010 you are advised to use a trusted certificate for all externally reachable Exchange services. (There are exceptions to this rule, but that’s a different bag of tricks, and requires different considerations before implementation.) Since this often means a number of services; Exchange ActiveSync, OWA, Outlook Anywhere and Exchange Web Services, it’s not unusual to use either a SAN-certificate (a number of DNS names included) or a wildcard certificate (*.domain.com). This is all nice and dandy, and you can easily install the certificate in a number of places and point the external DNS names to different IP addresses. But many companies do not have a long list of IP addresses to choose from, and will want to pool some of the services together on the same IP address. This is usually not a problem – both OWA and ActiveSync can be on the same DNS name and IP address without issues.

Autodiscover however might not play nice with all the other services. It is not uncommon to use ISA Server or Forefront TMG to publish your Exchange server – after all Microsoft kind of recommends that. (Even if you have something like a Cisco firewall on top of that.) With ISA/TMG you have great flexibility, but you can only have one SSL certificate binded to one IP. And you can only use one authentication method on a web listener.

This means that if you’re running mail.contoso.com binded to 10.0.0.1 with basic authentication you need to be aware of a couple of things before you hook up autodiscover.contoso.com to the same web listener:
– The POST to https://autodiscover.contoso.com/autodiscover/autodiscover.xml will use basic authentication. If you require client certificates for OWA and/or EAS, and have this on the same web listener, this test will fail. If you want a working Autodiscover you will probably want to bind this to a separate web listener that does not require client certificates.
– If http://autodiscover.fqdn.com/autodiscover/autodiscover.xml requires authentication in any way this Autodiscover test will fail with a 401. Autodiscover does not attempt to authenticate to this address even if the credentials are available to the client performing the Autodiscover as it it not correct per the ActiveSync protocol to do so. (Since it is not SSL-encrypted.)

Unrelated to these restraints you should also keep the following in mind:
https://contoso.com often redirects to http://www.contoso.com (unless you’re filtering the virtual directory part) so if you can’t “fix” this in your domain this is ok.
– The SRV record support is nifty, but I would not trust all clients to implement this. (Meaning that if you rely solely on this test you should not be surprised if not all devices are able to use Autodiscover to configure mailboxes.)

An ActiveSync client should attempt at least three of these tests, (SRV queries might have lack of support on the OS level), as far as I’m concerned. Microsoft requires full implementation of Autodiscover for a client to achieve certification in the Exchange ActiveSync Logo Program, but I do not know if there are exceptions for SRV records. I have not implemented SRV support yet since my code is running on .Net 3.5, which does not include the necessary API calls. .Net 4.0 does, so I have to consider whether to “upgrade” my code to a newer version of .Net or use a third-party DNS API.

Of course it is still fully possible to have ActiveSync clients happily syncing away without automatic configuration and instead require users to manually enter the server address, but this may impact other operations as well. Correct implementation of Autodiscover includes handling HTTP 302 and HTTP 451 responses in addition to the initial configuration. If your mailbox is moved to a different Client Access Server (with a different external address) Exchange will provide the new address in a response, and a proper client should handle this either by parsing out the new server from the headers, or perform a new Autodiscover if necessary. If not – sync will break until you manually change the server address. (My personal experience is that the iPhone handled this correctly when my mailbox was moved, while the Android I was using at the time simply stopped working reporting that the server was not reachable.)

Support for Exchange 2010 Service Pack 2 was/is still on my to-do list, but since it has yet to be released in a beta I have not been able to do anything related to this. The documentation for the ActiveSync protocol is not updated for SP2 yet either.

The executable can be found over at http://mobilitydojo.net/downloads

Leave a Reply

Your email address will not be published. Required fields are marked *

*