iOS 6.1 currently causing issues with Microsoft Exchange

If you are using an iOS 6.1-based iPhone or iPad to connect to a Microsoft Exchange-based server, you may be causing problems for the PC that's running that server program. This week, Microsoft issued an alert that revealed issues with iOS 6.1 products not working well with Microsoft Exchange PCs.

The support alert from Microsoft states:

When a user syncs a mailbox by using an iOS 6.1-based device, Microsoft Exchange Server 2010 Client Access server (CAS) and Mailbox (MBX) server resources are consumed, log growth becomes excessive, memory and CPU use may increase significantly, and server performance is affected.

The alert states that both Microsoft and Apple are aware of the issue and are trying to fix the problem. In the meantime, Microsoft has three workarounds: one is to remove and later re-create the Exchange account connection for the iOS 6.1 product, while another is for the administrator of the Exchange server to create a custom throttling policy for those same users.

The third solution is the most drastic. Microsoft says that Exchange server admins can simply block access to all iOS 6.1 users until a solution can be found and implemented by Microsoft and Apple.

Source: Microsoft Support | Image via Microsoft

Report a problem with article
Previous Story

Wikipedia adds watchlists to mobile web app

Next Story

Rumor: HP to sell Android-based tablets?

24 Comments

Commenting is disabled on this article.

So just disabling the calendar sync should fix the issue, as opposed to asking the user to remove the accounts all together?

I already have people telling me that this isn't an iOS issue but an "Exchange issue"... love how people always try to blame it on non-apple products for something an apple product is causing... thousands of other devices out there that are non-ios 6.1 and not an issue...

neufuse said,
I already have people telling me that this isn't an iOS issue but an "Exchange issue"... love how people always try to blame it on non-apple products for something an apple product is causing... thousands of other devices out there that are non-ios 6.1 and not an issue...

In fairness I think it's both -- Apple is to blame for not playing nice with calendaring requests (they've done poorly there for a while) and Microsoft for not making the EAS protocol more durable to these kinds of DOS problems. I've seen Android and even windows phone cause problems as well with EAS, so it's really more about the protocol in those cases (or the vendor's adherence to the protocol)

neufuse said,
I already have people telling me that this isn't an iOS issue but an "Exchange issue"... love how people always try to blame it on non-apple products for something an apple product is causing... thousands of other devices out there that are non-ios 6.1 and not an issue...

While there is certainly an iOS bug here, it is a basic rule of secure programming that server software shouldn't trust it's clients and the clients shouldn't be able to do anything to cause the server to fail.
Both sides have to lift their game in this case.

mram said,

In fairness I think it's both -- Apple is to blame for not playing nice with calendaring requests (they've done poorly there for a while) and Microsoft for not making the EAS protocol more durable to these kinds of DOS problems. I've seen Android and even windows phone cause problems as well with EAS, so it's really more about the protocol in those cases (or the vendor's adherence to the protocol)

Technically this isn't a dos type problem. Apple (again I might add) simply delivered sloppy coding where calendar items (meeting request in this case yet again) are ending up in a loop. This loop in turn leads to extensive logging. On most systems this won't be a problem (case in point my ex 2010 box) on some it apparently is. In any case, this is quite clearly a coding error on the client side, and as said the second time in a row now from Apple.

mram said,
In fairness I think it's both -- Apple is to blame for not playing nice with calendaring requests (they've done poorly there for a while) and Microsoft for not making the EAS protocol more durable to these kinds of DOS problems. I've seen Android and even windows phone cause problems as well with EAS, so it's really more about the protocol in those cases (or the vendor's adherence to the protocol)

I respectfully disagree. When you licence the protocol off Microsoft one of the perks you get is access to engineers to bounce questions off. The issue isn't Microsoft but Apple's paranoia regarding secrecy and their refusal to actually investigate issues and address them in a timely manner without firstly denying that the issue exists.

Shouldn't the question be asked as to why Android doesn't cause a similar problem - if providing exchange support was a giant PITA then we'd see similar problems appear left, right and centre but that simply isn't the case.

Mr Nom Nom's said,

Shouldn't the question be asked as to why Android doesn't cause a similar problem - if providing exchange support was a giant PITA then we'd see similar problems appear left, right and centre but that simply isn't the case.

But android devices DO cause similar issues at times. It's not universal, but that's because android devices are not by themselves universal, nor is the activesync protocol licensed universally for the OS. But that doesn't mean that the one-off android devices do not cause activesync runaway logfile issues. It just never generates news because you can't blame the entire OS and it doesn't have the uniformity that apple has...

Also to be fair because it probably would be an app-level issue, these things tend to be resolved or handled faster and better.

But trust me, I've seen everything, including Microsoft phones, cause activesync runaway profile issues.

Alternatively, you can read about the cause and a temporary fix for iOS 6.1 from http://support.apple.com/kb/TS4532

When you respond to an exception to a recurring calendar event with a Microsoft Exchange account on a device running iOS 6.1, the device may begin to generate excessive communication with Microsoft Exchange Server. You may notice increased network activity or reduced battery life on the iOS device. This extra network activity will be shown in the logs on Exchange Server and it may lead to the server blocking the iOS device. This can occur with iOS 6.1 and Microsoft Exchange 2010 SP1 or later, or Microsoft Exchange Online (Office365).

* An exception is a change to a single instance of a repeating calendar event.

Resolution
Apple has identified a fix and will make it available in an upcoming software update. In the meantime, you can avoid this bug by not responding to an exception to a recurring event on your iOS device. If you do experience the symptoms described above, disable then reenable the Exchange calendar on your iOS device using the steps below.

Go to Settings > Mail, Contacts, Calendars
Select the Exchange account from your Accounts list.
Turn the switch for Calendars to OFF.
Wait ten seconds.
Turn the switch for Calendars back to ON.

Much less drastic.

I have no seen any indications that MS will fix this security bug (a denial of service attack, if a non-malicious user can do it due to a bug client side, imagine what a malicious user would do..).


Rosyna, as you see from the Apple support article this is an iOS bug. A security bug would mean someone is gaining access to resources they do not have permission to access and that is not taking place here.

scorp508 said,
Rosyna, as you see from the Apple support article this is an iOS bug. A security bug would mean someone is gaining access to resources they do not have permission to access and that is not taking place here.

It's a security bug because it can take down the entire Exchange Server by filling up the HDD with log files. This should not be possible. a server should not allow a client with low permissions to make the server inaccessible.

There are two bugs. 1. The iOS bug that causes it to keep hitting the server over and over and the 2. The Exchange (and Office 365) security bug that allows this to become a denial of service attack.

(Other EAS server implementations do not seem to have either problem).

Exchange 2010 can use throttling policies to prevent this kind of behavior from bringing down Exchange. Since the tools exist, but not all administrators actually leverage them, I wouldn't classify it as being a 'security bug'.

Rosyna said,
(Other EAS server implementations do not seem to have either problem).

This isn't necessarily true. Not every device "plays nice" with EAS, and generates transaction log file issues, especially in cases where there are bad profiles or failed resyncs of devices.

Microsoft in my opinion are more to blame for building a framework for connectivity with nothing more than throttling policies to address, and even then it's on a per-user basis, not a per-device basis. If you have an iPhone and an android tablet, you'd be subject to one policy for both devices.

Rosyna said,

It's a security bug because it can take down the entire Exchange Server by filling up the HDD with log files. This should not be possible. a server should not allow a client with low permissions to make the server inaccessible.

There are two bugs. 1. The iOS bug that causes it to keep hitting the server over and over and the 2. The Exchange (and Office 365) security bug that allows this to become a denial of service attack.

(Other EAS server implementations do not seem to have either problem).

Nonsense. The Exchange admin can, and should have only provisioned devices allowed to connect to EAS. Therefore I can refuse access to iOS 6.1

If your mail client had a bug that hammered the crap out of your POP3 server, would you blame the POP3 vendor or the client? Apple have failed to inter-op as per the spec.
I have circular logging enabled so don't need to worry too much, plus a lot of space for the log files, but the logs in this case are doing what they are designed to do: log all transactions. The client is spamming the server and no causing an issue other than the server is logging every failed transaction.

Apple are releasing a fix for their buggy EAS implementation in iOS - not for the first time I should add.

mram said,

This isn't necessarily true. Not every device "plays nice" with EAS, and generates transaction log file issues, especially in cases where there are bad profiles or failed resyncs of devices.

Microsoft in my opinion are more to blame for building a framework for connectivity with nothing more than throttling policies to address, and even then it's on a per-user basis, not a per-device basis. If you have an iPhone and an android tablet,
you'd be subject to one policy for both devices.

I can create a policy that blocks all devices other than the ones I pre-approve, or block based on user account or type of device ID / OS. If those aren't enough option SCCM gives more control.

stevehoot said,
If your mail client had a bug that hammered the crap out of your POP3 server, would you blame the POP3 vendor or the client?

Simple, you blame both the client and the server vendor. The client for improperly sending requests repeatedly and the vendor for not having a server that handles bad client requests.

Rosyna said,

Simple, you blame both the client and the server vendor. The client for improperly sending requests repeatedly and the vendor for not having a server that handles bad client requests.


But the server can handle these bad requests, its a matter of configuration.
That it logs failed transactions per default and iPhone's sent uit enough to fill harddrives... With Exchange having features to prevent this from happening OOTB, I don't see how's Exchange to blame here.

@ xendrome: pretty much. We do ours everyday I believe. However, the other reason I think we're not bad off is only some of IT and upper mgmt. have iPhones. Maybe around 60 people?

Another fix is to delete your transaction logs after a backup. That's what we're doing now and were keeping the issue at bay.

briangw said,
Another fix is to delete your transaction logs after a backup. That's what we're doing now and were keeping the issue at bay.

Transaction logs are pruned after any successful backup. If yours are not, there's something wrong with the backup process.

The problem here is usually for most companies that the trans logs get generated rapidly and fill the logfile volume (assuming there is one) prior to a backup being able to successfully clear them.