[MacTUG] [windows-hied]: Apple iOS / Exchange 2010 issue

Tue May 28 16:09:20 EDT 2013

This email from his Windows listserv, one of the guys in Eng Comp thinks this may help with the Outlook bandwidth issue. I am not sure. In both cases, their is a program consuming bandwidth but the OSes are different.

YMMV,
Marlon

-------- Original Message --------
Subject: 	Re: [windows-hied]: Apple iOS / Exchange 2010 issue
Date: 	Wed, 20 Feb 2013 20:37:19 +0000
From: 	Michael Chung <mchung at haas.berkeley.edu>
To: 	McCabe, Michael <mjmccabe at uci.edu>, Andrew Laurence
<atlauren at me.com>, Rupprecht, James R. <jimrupprecht at ku.edu>
CC: 	'windows-hied at mailman.stanford.edu'
<windows-hied at mailman.stanford.edu>

Looks like Apple released iOS 6.1.2, which claims to address the calendar sync behavior in ActiveSync.

http://support.apple.com/kb/DL1639
http://osxdaily.com/2013/02/19/ios-6-1-2-download/

Curious if you see improvements after your users install this update. I have a number of users whose iOS are generating large amounts of transaction logs and ExMon indicates they have over 5000 sessions to their mailbox. Our servers are able to handle the additional CPU load so I haven't had to resort to throttling or a full block on iOS 6.1 (additionally, I have seen unusually high transaction log growth attributed to iOS 5 and 6.0 as well).

I have advised one of my problem users to install the 6.1.2 update on her device and will be watching to see if it has a positive effect.

Michael Chung
Systems Administrator
Haas Enterprise Computing & Service Management
mchung at haas.berkeley.edu | 510-643-3887

-----Original Message-----
From: windows-hied-bounces at lists.stanford.edu [mailto:windows-hied-bounces at lists.stanford.edu] On Behalf Of McCabe, Michael
Sent: Thursday, February 14, 2013 9:38 AM
To: Andrew Laurence; Rupprecht, James R.
Cc: 'windows-hied at mailman.stanford.edu'
Subject: Re: [windows-hied]: Apple iOS / Exchange 2010 issue

We got hit very hard by the issue with twice daily reboots required for a week.  This was painful because Apple devices are used for some Electronic Medical Records application so we have a lot of them.  This hit us in odd ways because iOS devices were the first ones who couldn't connect via ActiveSync.  But then a random number of Outlook 2010 clients couldn't log in.  Some Android devices couldn't connect via ActiveSync.  Over a few days it was hard to identify because the issues weren't immediate.

In one case one device tried to sync 50,000 times for one calendar in a very short time.  Three devices sent almost 100,000 sync requests in a day.  I opened a case with Premiere and after a few days they outlined the results as being this iOS 6.1 update causing repeated sync requests.  Not the previous 6.0 calendar issue where appointments are hijacked.  The fixes were clunky at first, but there was no choice.  The few offending devices were causing RPC Web services to fail on our two CAS servers.  That was impacting people across all clients.  We've decided to go with using load balancers to throttle the meeting request connections from iOS 6.1 devices.  Until that we used an alert to trigger on excessive CPU usage which informed us that we may need to review the event logs for an offending device.  In most cases people had multiple iOS devices which meant we blocked their ActiveSync access completely.

Our CIO contacted our rep at Apple to complain and a case was opened with AppleCare.  Everyone we heard from at Apple was "shocked" and was unable to get any feedback from their iOS team that this was indeed a problem.  Three days later I got an acknowledgement that this was an issue and to expect an update from Apple.  Not impressed by their lack of ownership or feedback at a time they want us to buy a very costly support agreement.

One outcome we found a day ago was that these calendar items syncing caused one user to have the same appointment thousands of times.  We saw his mailbox go from 300MB to over 2GB and get locked out.  Three appointments too up 1.9GB.  I recognized his name as one of the few people we had to block from ActiveSync in the first few days this went on.

Mike

Michael McCabe | Programmer IV | Health Affairs Information Services University of California, Irvine
200 S. Manchester Avenue, Suite 514 | Orange, CA 92868
Office: 714.456.6869 | Fax: 888.237.1180 michael.mccabe at uci.edu

-----Original Message-----
From: windows-hied-bounces at mailman.stanford.edu [mailto:windows-hied-bounces at mailman.stanford.edu] On Behalf Of Andrew Laurence
Sent: Wednesday, February 13, 2013 11:52 AM
To: Rupprecht, James R.
Cc: 'windows-hied at mailman.stanford.edu'
Subject: Re: [windows-hied]: Apple iOS / Exchange 2010 issue

This guy applies a throttling policy just to 6.1 devices.

http://ucken.blogspot.ca/2013/02/assigning-throttling-policy-to-all-ios.html

+1 Insightful

-Andrew

On Feb 13, 2013, at 10:52 AM, "Rupprecht, James R." <jimrupprecht at ku.edu> wrote:

> We've only had about 50 devices generating the error so far but we are doing proactive notifications of all Apple device users via email. For the ones not on iOS 6.1 we are advising them not to update. For iOS 6.1 we are advising them not to make/change/accept calendar items. For the affected ones we are providing mitigation steps.
>
> Jim Rupprecht
> Enterprise Architect, Microsoft Technologies The University of Kansas
> Information Technology
>
> ----- Original Message -----
> From: windows-hied-bounces at lists.stanford.edu
> [mailto:windows-hied-bounces at lists.stanford.edu] On Behalf Of Resnick,
> Michael L - (mresnick)
> Sent: Wednesday, February 13, 2013 12:48 PM
> To: Andrew Laurence
> Cc: 'windows-hied at mailman.stanford.edu'
> Subject: Re: [windows-hied]: Apple iOS / Exchange 2010 issue
>
> Hi Andrew,
>
> I'm actually seeing the massive number of hits from 6.0 devices (e.g. 50,000+ POST hits logged per day per device) rather than the 6.1 devices. The 6.1 devices are above normal number of hits (4,000+ hits) compared to Android devices (~200 hits), but nothing, so far, as bad as the 6.0 devices. And I noticed this back in early December before 6.1 was released, which is curious to me. Perhaps this is just an anomaly unique to our environment.
>
> The good news is that, even with ~5,000 iOS devices connected, it isn't impacting performance on any of our servers, except for the increase in transaction log generation, which, so far, is well within management parameters. So, we have no plans to block any devices yet. A few users have reported reduced battery life on the 6.1 devices, and we have suggested the workarounds mentioned in Microsoft KB article (http://support.microsoft.com/kb/2814847?wa=wsignin1.0).
>
> No other issues reported, yet. :)
>
> -Mike
>
> Mike Resnick
> Systems Administrator, Principal
> UITS - University of Arizona
> mresnick at email.arizona.edu
> 520-626-3697
>
> From: Andrew Laurence [mailto:atlauren at me.com]
> Sent: Wednesday, February 13, 2013 11:28 AM
> To: Resnick, Michael L - (mresnick)
> Cc: 'windows-hied at mailman.stanford.edu'
> Subject: Re: [windows-hied]: Apple iOS / Exchange 2010 issue
>
>
> On Feb 13, 2013, at 9:25 AM, "Resnick, Michael L - (mresnick)" <mresnick at email.arizona.edu> wrote:
>
> Did anyone else first see drastic increases in transaction log generation starting in the beginning of December as opposed to just recently? We have a 25,000 user deployment, so there are a lot of iOS devices around campus. Around Dec 5th, I noticed massive increases in trans logs on some of our DBs, especially to our lagged DB copies. All of the users with the largest amount of Log Record Counts/Bytes were using iOS devices (iPhone/iPad). But I didn't see any increases/spikes in CPU utilization and no performance degradation has been perceived. Even with a lot of users on 6.1 now, I haven't seen CPU utilization increases or and performance issues. But I am still seeing massive amounts of trans logs and hits in the IIS logs from users on iOS devices with versions ranging from 6.0 to 6.1 on the order of 50,000-80,000 hits in a single day from a single device.
>
> Just curious what others are seeing/doing in their environments.
>
> This first surfaced in Exchange forums/blogs on Thursday 2/7.  Microsoft posted an advisory yesterday morning 2/12, and yesterday evening Apple posted one as well.  It seems that if the user responds to an event which is an exception of a repeating series, the device stores something bad and then keeps sending updates to the server.  Microsoft points to some tools for log monitoring to pinpoint misbehaving devices; Apple says they're going to fix it in an update.
>
> MS suggests disconnecting misbehaving devices, or disallowing 6.1 clients.  Apple points to a workaround on the device which wipes the local calendar store and reloads from the server.
>
> http://support.microsoft.com/kb/2814847
>
> http://support.apple.com/kb/TS4532
>
> At one site here, we've seen three bad devices out of >500 with 6.1.  Another has been hit much harder; last I heard they were going to put a block rule in their F5 appliance.
> https://devcentral.f5.com/community/group/aft/2165837/asg/50
>
> --
> Andrew Laurence                      Office of Information Technology
> atlauren at uci.edu                     University of California, Irvine
>
>
> --++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**==
> windows-hied mailing list
> windows-hied at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/windows-hied
>

--++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**==
windows-hied mailing list
windows-hied at lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/windows-hied

________________________________

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
--++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**==
windows-hied mailing list
windows-hied at lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/windows-hied

--++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**==
windows-hied mailing list
windows-hied at lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/windows-hied