iOS Devices Using ActiveSync Are Doing an Unexpected Full Sync or Reload of Exchange Data

 

Symptom:

Your Exchange data may unexpectedly reload on some or all of the iOS devices in your organization. This includes Exchange email, contacts, and calendar information.

Environment: Exchange 2007, Exchange 2010, or Exchange 2013 published externally using Internet Security and Acceleration (ISA 2004 or ISA 2006) Server, Forefront Threat Management Gateway 2010 (TMG 2010) or Unified Access Gateway 2010 (UAG 2010).

Cause:

This issue is seen when the iOS devices receive an HTTP 500 error in response to consecutive requests. The ping that the client initiates is critical to the Direct Push technology that Exchange ActiveSync relies on for determining when there is new information to be pushed to the client.

For more information on Direct Push and how it works see the below links

https://technet.microsoft.com/en-us/library/cc182244.aspx

https://technet.microsoft.com/en-us/library/cc182236.aspx

Diagnosing this issue:

Apple has addressed this issue on their support forum here and has some recommendations for diagnosing this at the client. It is my understanding that Apple support has to pull the ActiveSync logs off the iOS devices.

From the ISA/TMG standpoint, diagnosing this involves a couple of things. Start Live Logging on ISA/TMG and filter for traffic that is using the ActiveSync rule for your organization. If there are multiple requests that are showing as Failed and an Error 64 is indicated as the cause then we need to investigate further.

A Microsoft Support Engineer can gather application level tracing using our Best Practices Analyzer  and more specifically the Data Packager.

In the ISA/TMG tracing which will need to be converted by Microsoft we will typically see ActiveSync conversations failing with error code 64(ERROR_NETNAME_DELETED) and will be followed by a response to client of HTTP/1.1 500.UAG Tracing would not show the (ERROR_NETNAME_DELETED) but you should still see a HTTP/1.1 500 being returned to the client. 

Resolution:

To resolve this we need to determine why the communication from the ISA/TMG server to the CAS is being interrupted or prevented altogether.

In most, not all, cases there are environmental factors at the root of the issue. Typically it is caused by a misbehaving network device or devices. The most often seen culprit is a 3rd party hardware load balancer. We have also seen issues with 3rd party firewalls and even Antivirus installed on ISA/TMG that is causing the sporadic network connectivity.

How firewall timeouts can affect direct push is discussed here.

Figuring out the culprit is just a process of elimination. If Antivirus has been installed recently or updated recently on ISA/TMG then remove it completely and reboot your servers. Is the issue still happening? If you can bypass your hardware load balancers then do it by creating a Web Farm on ISA/TMG that goes directly to the CAS Servers. Did that resolve your issue?

Note: Using the built-in load balancing capability of Web Farms in ISA/TMG can be a valid and cost effective alternative to hardware load balancers. For more information on this feature please read this link.

Conclusion:

Microsoft’s Direct Push technology is a essential part of using ActiveSync on your devices. iOS phones are not as forgiving of interruptions to the heartbeat process as some other vendors devices. For this reason you may have issues with iOS devices doing full sync reloads. Troubleshooting these issues can be tricky but I hope I have given you the information to adequately resolve your issue in a timely manner.

Please see my follow up to this post. https://blogs.technet.com/b/keithab/archive/2015/09/04/ios-devices-using-activesync-are-doing-an-unexpected-full-sync-or-reload-of-exchange-data-part-2.aspx

Author: Keith Abluton, Sr. Support Escalation Engineer

Technical Contributor: Bryan Talbert, Sr. Support Escalation Engineer