So here is the skinny on what went awry with the transition of AEMS to Exchange 2010 Client Access Servers.

Although most users did not encounter any difficulties, a sizable subset encountered difficulties which can be broken down into the following categories, difficulties which were serious enough that it was felt that a backdown of our change was warrented:

IMAP4 issues: we’ve already identified and corrected one source of issues for IMAP4 users, but are still trying to characterize a remaining issue (a process made more difficult by the fact that we have reverted our change).

Droid and iPhones running pre-IOS4 software: In a 2010/2007 coexistence scenario, when an ActiveSync devices connects to the 2010 CAS, Exchange looks up the account, notices that the user still has their mailbox on Exchange 2007, and sends out an HTTP 451 error, saying “Hey, you can’t talk to that mailbox here, but if you go over this legacy address, you should be able to connect.” This does not seem to work with older iPhones or with any Android phones. We are currently trying to figure out a solution that doesn’t involve having each user of these devices manually modify their device settings to point to legacy.austin.utexas.edu, then reconfiguring to point the device back to wmail.austin.utexas.edu once their mailbox is moved, a dicey prospect at best. Unfortunately, the Microsoft engineer with which I was speaking this afternoon was not optimistic about us finding a good alternative solution for that.

Users with custom-hosted e-mail domains using non-Outlook clients: We have noted widespread problems for customers who are not using Outlook and have their client software (mobile or desktop) configured to use an email address other than their @austin.utexas.edu addy. This includes custom hosting customers, and folks who have their primary SMTP address set to use their @mail.utexas.edu address. The upshot for this is that autodiscover is broken for those address spaces, resulting in their connection not getting properly redirected to legacy.austin.utexas.edu. We MAY have come up with an interim solution which would involve DNS changes in those hosted domains. Alternatively, impacted users can configure their clients with their @austin.utexas.edu. (Outgoing mail would still APPEAR to come from their other address.)

I should point out that any user that had reconfigured their client to point to legacy.austin.utexas.edu in order to make it work need not make any changes at this point, but they will have to revert that change once we finally migrate their mailbox to 2010.

I had said in my presentation last week that problems inevitably crop up with a transition as big as this. I REALLY would not have minded being proven wrong….

Update (June 14):

For the three main issues, here is where we currently stand on trying to come up with a fix:

1) IMAP4 with NTLM – support for this seems to have been dropped from Exchange 2010 RTM, but quietly restored in SP1. Our MS support engineer is double-checking this as I type, but I suspect that, at worst, we will be able to do on this will be to tell IMAP4 users to make sure their clients are set to use Password auth. At best, we’ll figure out server settings to get this working.

2) Autodiscover failing with custom hosted domain email addresses – this will be relatively simple to fix. It requires a DNS change for every domain for which AEMS does custom address hosting.

3) Android failing to redirect – this is due to a bug in the Android code, which Google will likely not be fixing until the end of the year.  Having every Android user reconfigure their client – twice, once for the wmail switchover and once for their mailbox move – is obviously not an acceptable solution. We may be able to address this issue the same way in which we are handling Snow Leopard’s inability to handle the same redirect – setting up an iRule to on the F5 load balancers to route all traffic from these devices to legacy.austin.utexas.edu to handle the transition of wmail to Exchange 2010, identify those users by parsing our IIS logs, then move those users to Ex2010 mailbox servers in a single batch while removing the iRule. Both setting up the iRule and scouring the IIS logs are somewhat complicated by the fact that Android devices are bizarrely not consistent in how they populate the user-agent string in the HTTP headers, frequently filling it with manufacturer and device model (which is rather useless data for protocol logging), rather than something consistent, useful and simple to key on like “Android v#.# EAS”.