In late December, 2012, I posted the saga of narrowing down a set of iPhone / iPad symptoms that periodically manifest themselves and usually arrive hand in hand. Those symptoms include noticeably diminished battery life, surging 3G/4G data consumption, and devices that run warmer to the touch than normal. If you’d like my history with this going all the way back to iOS 4.x, click here and then follow a link back to this post when finished with the first. Today’s post is chapter two of what I hope is only a trilogy.
When we left off in December, we’d narrowed our iPhone / iPad problems down to runaway interaction between problematic iDevices and my employer’s corporate e-mail server running Microsoft Exchange 2003 Service Pack 2. These interactions are documented in the Internet Information Server (IIS) logs on our server running Exchange ActiveSync, and are stored by default in our case at c:\WINDOWS\system32\LogFiles\W3SVC1. While a properly-functioning iPhone may connect to our Exchange server a few hundred times per day, a runaway device will connect up to tens of thousands of times per day. This excess traffic will continue unabated on an offending device until manual intervention is taken. If too many devices in an organization are doing this at once, it creates a sort of denial-of-service attack against the Exchange ActiveSync server.
It’s important to note that this issue may affect more than just the Exchange portion of the iOS e-mail client. I’ve received and observed feedback regarding the client-side symptoms – battery drain, 3G/4G data surge and warm devices – from people connecting to other push e-mail services including Hotmail and iCloud as well. Of course end-users and business network administrators like myself aren’t privy to what’s happening at the other end of those cloud services.
Subsequent to my December post, this iOS / Exchange issue finally reached mainstream consciousness following the release of iOS 6.1. Apple went as far as issuing a rare acknowledgement that an issue was known to occur when connected to Microsoft Exchange 2010 SP1 or later, and that it is triggered by responding to an exception to a recurring calendar event sent to a Microsoft Exchange account. Apple said nothing of Exchange 2003 that I am aware of.
I talked about and documented several of my interactions with Apple in the December post. I shared my mild frustration in getting past their basic support to the point that they believed that I had a legitimate iOS issue. On January 9th, 2013, my issue was escalated yet again to a person that I’ve been in fairly regular contact with since. I provided raw log files at Apple’s request to be forwarded to their engineering team. And I’ve had nothing but positive interaction with Apple since. I know from Google Analytics that Apple is familiar with my original blog post. As I’m writing this follow-up, my little blog has received 39 visits from a network labeled, ‘apple inc.’, another 8 visits from ‘apple inc. – 10g ashburn ide’, and 1 visit from ‘apple computer’ since the original post went live.
Apple released iOS 6.1.2 on February 19th, 2013. The update description read in full, “Fixes an Exchange calendar bug that could result in increased network activity and reduced battery life.” I received a few e-mails from friends as far away as China pointing out that our issue might now be fixed. Three days later I sent out a memo to our iOS users asking any who had not already done so to upgrade to iOS 6.1.2.
On Sunday, February 24th, a single CDMA iPhone 5 running iOS 6.1.2, noted in our IIS logs as ‘Apple-iPhone5C2/1002.146’, contacted our Microsoft Exchange ActiveSync server 69,878 times that day. Keep in mind that there are only 86,400 seconds in a 24-hour period. By way of comparison, my iPhone 4 checked in 336 times during the same span of time. Upon discovery, I notified my contact at Apple and sent him the log at his request.
What To Do With Your Runaway iPhone
Since the December post, we’ve learned that fixing runaway iDevices is much simpler than our original course of action, which consisted of wiping them out and setting them up as if they were new. Neither that action, nor simply deleting and re-adding an Exchange account, seems to be necessary. In fact, resolving our latest runaway iPhone proved to be as simple as turning off the iPhone’s calendar sync on the Exchange account momentarily, and then turning it back on.
For Exchange Administrators
Some organizations are taking technical means to bar iPhones running iOS 6.1 through 6.1.2 from contacting their Exchange servers. If you have a great many iPhones, this step may be absolutely necessary in order to keep your e-mail environment up for everyone else. At the very least, you should consider alerting all users to stop accepting calendar invitations and updates via their iPhones and iPads. For those of us with far fewer devices to manage, simply keeping abreast of the server logs and working with affected users may be enough. As I write this, our IIS log for Saturday is already several times larger than it should be. It wouldn’t be that difficult to automatically BULK INSERT each day’s log file into a SQL table and then query for the number of connection attempts by each user’s iPhone or iPad per day. I work with a great DBA who may be called upon to do that for us if Apple doesn’t come out with a fix real soon.
While iPhones are wonderful pieces of technology that can do a great many things, there are exactly two functions that every smartphone must do reliably, bar none. One is to make phone calls. The other is to handle mobile e-mail, calendaring and contacts. The fact that the premier device from one of the most well-regarded companies on earth has problems with one of these basic necessities is fairly disconcerting. One wonders how hard it could possibly be to program in an upper limit to the number of attempts to update a single calendar invitation!? I’m not yet at the point that I’m going to steer anyone away from the iPhone and iPad. But I really hope that Apple can get this right in iOS 6.1.3 or soon thereafter. Before I start giving BlackBerry a second look.
[While I hoped that this issue would ultimately be resolved by iOS 7, we’ve now seen this behavior in iOS 7 and 7.0.2 as well. Follow this link to the next post.]