Microsoft has come a long way from the bad old days of Windows 95 and blue screens of death. Recently I had to add a new domain controller to a domain, rename that domain, create a new Exchange server and migrate all the users mailboxes to that new server. All in the space of a few days because the old hardware was crashing constantly and nobody was quite sure how long the hardware would last.
I thought with all those things in a short space of time surely something would crash and cause headaches. Just the task of renaming a production AD forest is fraught with danger, but full credit to Microsoft it went smoothly and was pretty straight forward, once you have all the pre-requisites in place that is. The only major problem I did have in the end was getting Exchange OWA/OMA working with Android phones.
The symptom was that when trying to add an Exchange account on the Android phone it threw up a less than helpful error;
"You typed an incorrect server address or the server requires a protocol version that Email doesn't support"
I doubled checked the server address was definitely correct so I knew it had to be related to the protocol version part of the error. The first test then was to try the web-based interface hitting up https://servername/exchange. This kind of worked, allowing me in but throwing server 500 errors. I hunted around a bit dug through the logs both IIS and event logs in Windows and after a bit of searching found out you need to give people “Log on Locally” access so they can use webmail. As the Exchange server is also an AD that access is restricted by default so I had to change the Group Policy to allow it. After that I could logon to webmail and access email just fine.
So the next thing I tried was to see if the Outlook Mobile Access itself worked by going to https://servername/oma, that also seemed to work fine, presumably it would’ve had the same server error as above but fixing webmail access probably also fixed mobile access. So I tried the phone again thinking maybe it would just work now, but still no joy. After finding this article http://code.google.com/p/android/issues/detail?id=25648 I thought I’d give Touchdown a try. Low and behold it works, however it seems a lot smarter than the default Android mail app, it went through checked is it Exchange 2007, is it 2003, etc. Now while it worked it wasn’t exactly a solution I could offer to the client, but did instill hope that it was close.
I tested the debug mode on email on Android as suggested in the above post however it didn’t seem to log anything despite having logging turned up to the fullest, so I was stuck with the IIS logs. The most interesting thing from the log files in C:\WINDOWS\system32\LogFiles\W3SVC1\ was this line
"2012-MM-DD HH:MM:SS W3SVC1 192.168.X.Y OPTIONS /Microsoft-Server-ActiveSync Cmd=OPTIONS&User=DOM\User& DeviceId=SAMSUNG123456789012345&DeviceType=SAMSUNGGTI9100&Log=VNATNASNC:0A0C0D0FS:0A0C0D0SP:0C0I0S0R0S0L0H 443 DOM\USER ip.add.re.ss SAMSUNG-GT-I9100/100.40003 200 0 0"
I’ve sanitized it in obvious places, but the basic gist is the phone sends an “OPTIONS” directive to the server to find out it’s capabilities which according to the 200 response message IIS sends back fine, however it’s right after this the phone gives up complaining about protocols not being supported. The answer then seemed easy, all I had to do was get the server to return the correct options, the phone would recognize them and off it would go. The reality however is a lot harder (well easier as the solution turned out to be). It seems there’s nowhere in IIS you can set the OPTIONS response, and as this is all over https you can’t even get any real visibility of requests and responses, nor can you simply telnet to port 80 and fire some requests at the server to test as you need to do the SSL/TLS handshaking first.
Microsoft you have made your OS a lot more stable, but please now give us decent tools to be able to debug and troubleshoot problems. Oh yeah and another thing why are all IIS logs in UTC, it makes sense on one level but trying to find things split over a day when it’s not midnight according to the server’s locale is just annoying.
In the end I could find no information about how to change OPTIONS or even what IIS sends back, nor could I find anything from Google about what the Android expects as a correct response. I tried adding RPC over HTTP, and playing with everything else almost that I could turn off or on but in the end to solve the problem I just upgraded to SP2 and hoped it didn’t break anything else on the server. After installing SP2 it just worked, whatever it was now sending back in OPTIONS the Android (and iPhones) clearly liked and email worked beautifully.
It was annoying though as the old server was on SP1 and worked fine, and from everything I could find the new one was setup the same way. It was also annoying from the Android side as 3rd party email software has more smarts and can deal with different setups but the default Email client is very inflexible when it comes to server setup.
Maybe next time a non IT person laughs at the solution of “Turn it off and on again” and ask why do IT people always say that. You now know the answer; Microsoft doesn’t give you enough tools to be able to troubleshoot or configure things, so the quickest and easiest path to a resolution is reboot it, upgrade it and/or re-install it.