Starting last December, and continuing in March of this year, we talked about a series of symptoms that often arrive hand in hand, sporadically, on Apple devices running various revisions of iOS 4, 5 and 6, up through 6.1.3. Those symptoms include devices running warm to the touch or even hot, a battery that may drain significantly faster than normal, and spikes in cellular data use of up to ten times the user’s normal pattern. While this trio of symptoms may well have more than one culprit, the many instances that I’ve personally witnessed have since been reduced to a single common cause. One with a quick solution.
If you’d like to read the years-long chain of events in order, including documented interactions with Apple along the way, you’re welcome to follow these links to part 1 and part 2 of the story. Today’s entry is the third – but not the final – installment. In the interest of time, we’ll try to get right to the point.
For All Of Us
If your iPhone, iPad or iPod touch ever begins running warmer than normal, or the battery drains twice as fast, or you get sticker shock on your next cellular bill, you’ll obviously want to quickly determine the cause. Fortunately, with iOS 7, this is easier than ever before. Begin by navigating to Settings > Cellular. Scroll down, and you’ll see data usage for native and 3rd-party apps directly under each application’s names. But don’t stop there. Also navigate into > System Services, and observe your usage here too. If your device connects to your company’s Microsoft Exchange e-mail environment, don’t be surprised to see a high number next to Exchange Accounts. And if you do, read on.
For Microsoft Exchange Users
As we alluded to earlier (after giving it away in the title, lead graphic and caption), virtually every instance of heat + battery drain + runaway data use that I’ve personally witnessed has been the result of a sudden-onset problem syncing a Microsoft Exchange calendar. When an iOS device encounters an error syncing an Exchange calendar, it simply retries. In fact, it retries every couple of seconds or so, nonstop, 24 hours a day, forever if you let it. Unfortunately this is nothing new.
This past weekend, an executive’s iPhone 5 (on Verizon) and his iPad 2 (Wi-Fi only), both running iOS 7, began exhibiting runaway connections to my employer’s Microsoft Exchange ActiveSync server. The user upgraded his iPhone 5 to iOS 7.0.2 over the weekend, but the problem persisted. In one 24-hour period, his iPhone checked in with our server 45,009 times, while his iPad connected 55,547 times. Normally we’d expect to see a single device connect a few hundred times per day rather than tens of thousands. After notifying the executive this morning, and asking him to perform the following fix, his problem went away for the time being.
If you think this may be happening to you, but aren’t sure, you might consider contacting your company’s IT Department or Microsoft Exchange Administrator. We’ll talk about what he or she can do in the next section. Having said that, the potential fix is easy, non-destructive, and you can try it out to see if it solves your problem. As illustrated below, you’ll simply navigate to your Exchange account settings, turn your Calendars off, and then turn them back on. While one step, “Delete from My iPhone”, sounds ominous, you’ll get your calendar entries back when you re-sync with the server. Further instructions follow in the next caption box. Please read and re-read them. And use them at your own risk.
For Microsoft Exchange Administrators
Keep an eye on the IIS log files on your Exchange ActiveSync server on a regular basis. By doing so, you may be able to identify a runaway iOS device before the users even know what’s going on. In larger environments, you’ll likely use automation and alerting tools to bring runaway devices to your attention very quickly.
The fact that this runaway connection problem has persisted now across four generations of iOS is a bit ridiculous. I’ve seen no Android devices exhibiting similar behavior in our environment, leading me to believe that it’s technically possible to engineer something that doesn’t do it. Common sense suggests setting some sort of timeout; a maximum number of retries before abandoning a particular calendar entry update. Last Spring I hoped that Apple would fix this situation with the next incremental release. We now know that they’ve failed to address it in their next major release, iOS 7. And that leaves all of us to live with the problem, monitor it, and execute this fix whenever necessary.