Recently, once of our Exchange users encountered an odd error while trying to use iCal to save a calendar event to our Exchange 2010 server. When trying to save a new event, the following error would crop up:

iCal can’t save the event “whatever the event name is” to the Exchange server.

The account *****@*****.**** currently can’t be modified. To discard your changes and continue using the version of your calendars that’s on the server, click Rever to Server. To save your changes on your computer until the problem is resolved, click Go Offline.

(Go Offline)     (Revert to Server) (Try Again)

Weird, eh?

After doing a bit of digging, we quickly found the issue documented here and there on the web. It seems that the problem stems from the fact that iCal does not by default use the system settings for Time Zones, and the above error pops up if there is a mismatch.

To fix the issue, it is necessary to go to the Advanced tab of the iCal preferences (iCal -> Prefererences -> Advanced) and enable time zone support. Also, check the system’s time zone settings (System Preferences -> Date & Time -> Time Zone) and make sure that the correct time zone is set there.

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”.

Once upon a time, there was an Exchange Connector for the Linux email client Evolution, and it was fairly good. Basically an OWA screen-scraper, it enabled Evolution to function as a Linux equivalent to Outlook, and (based upon my admittedly limited tinkering with it) it seemed to get the job done.

Then along came Exchange 2007, which changed how OWA worked, thus breaking the Exchange Connector. Linux users needing to connect to Exchange were faced with being restricted to POP3 or IMAP4 (assuming their Exchange admins had those legacy protocols turned on), using OWA (which is pretty limited in a non-IE environment), or running Outlook in a Windows VM.

But there are other options these days. In addition to the dramatically improved cross-browser OWA found in Exchange 2010, there is a MAPI plugin for Revolution! I’ve not yet tinkered with it, but this opens up quite a few options.

It is easy to forget that Windows XP will turn a decade old this fall. That is long run for an OS, and technology has continued to march on, yet many people still cling to XP. It is easy to see why. It was one of the more nimble and stable desktop OS releases that Microsoft has ever had. Being based upon the NT kernal, rather than DOS, it stood heads and shoulders above the old Windows 95, 98, and ME releases. Basically Windows 2000 Workstation with added MaxOS X inspired eye-candy, XP was a solid OS. When its successor, Windows Vista, was released in the fall of 2006, it was less than a resounding success. Sure, it was shiny and modern, but it was a resource hog with steep hardware requirements, and less stable than its predecessors. (To be fair, the latter issue was resolved with subsequent Service Pack releases.) Microsoft’s current desktop OS is Windows 7, which is essentially a souped-up Vista Service Pack, tuned to address many of the performance issues associated with Vista. It is a very nice OS, and Windows folk really should be using it, but a lot still aren’t.

I mention all of this because I ran into an issue last week caused by people clinging to XP. A user of my Exchange system (a Mac user running Outlook:mac 2011 – and yes, I have plenty of criticisms for that product as well) had found that some of the recipients of his digitally-signed messages could not read those messages. It turned out that the common factor amongst those recipients was that they were XP users. By default, when someone digitally signs a message using a personal cert on Outlook 2011, it uses SHA512 (a subset of SHA2) for its signing algorithm. But, as it turns out, the signing and encryption libraries in XP SP2 or earlier can only deal with messages signed using the SHA1 signing algorithm. XP SP3 added SOME SHA2 support, but it is quite limited.

http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx

So, if you are an XP user and can’t read a signed message, you’ll have to ask the sender resend the message either unsigned or signed with SHA1. And consider upgrading. Please.

Previously an internal-only tool, Microsoft’s Remote Desktop Connection Manager is now available for general use. And considering that I tend to have about a dozen RDC sessions open on my desktop at any given time, I have now doubt that I will find this utility useful.

All the gory details are available here.