You configure a server to run Microsoft Exchange Server 2003, Microsoft Exchange Server 2007, or Microsoft Exchange Server 2010.
The server that is running Microsoft Exchange Server has the Client Access Server (CAS) role.
You try to synchronize a mobile device.
In this scenario, the Exchange Server CAS server may run very slowly and not respond to a Microsoft Exchange ActiveSync request. When this issue occurs, the W3wp.exe process that is running under the MSExchangeSyncAppPool may use 100% of the CPU time.
Note On a server that is running Exchange Server 2003, the processing occurs on the back-end server. Therefore, the W3wp.exe process that runs under the ExchangeApplicationPool application pool on the back-end server may use the CPU time. Additionally, you may experience rapid transaction log growth.
This issue can occur if the mobile device tries to synchronize many contacts in a single request.
Note This synchronization request is frequently an unexpected POST of all the contacts that are on the mobile device. Exchange Server tries to validate the XML schema for each node for all the contacts. This may cause multiple memory allocations and excessive Microsoft .NET garbage collection.
Identify the users and devices that are causing the high CPU usage. To do this, follow these steps:
Collect the Internet Information Services (IIS) logs.
Use the following Log Parser Studio query to identify the problem users and devices:
/* Find Device/User Info for 100% CPU while syncing contacts */
Select TOP 5000 TO_TIMESTAMP(TO_DATE(date), TO_TIME(time)) as [Time],
cs-username as [User],
cs(user-agent) as DeviceID,
TO_INT(EXTRACT_PREFIX(EXTRACT_SUFFIX(cs-uri-query, 0, '_RpcC'), 0, '_')) As RPCCount,
sc-status as Status,
sc-substatus as SubStatus,
sc-bytes as [Bytes],
DIV(sc-bytes, 1024) AS [KBytes], time-taken, DIV(time-taken, 1000) as Sec, cs-uri-query
RPCCount > 2000 /* <-- Change RPC count as needed */
AND cs-uri-query LIKE '%Cmd=Sync%'
AND cs-uri-query LIKE '%Ty:Co%'
ORDER BY [Bytes] DESC
Note If a request takes longer than the IIS time-out to complete, the request is dropped and is not displayed in the IIS log.
Note Typically, the problem users have RPC counts over 2,000. These RPC counts frequently repeat at set intervals.
Inspect the returned data to identify high RPC count patterns for users and then match those users to users who have high contact item counts.
Test the issue again. To do this, follow these steps:
Temporarily disable a user from synchronization.
Recycle the MSExchangeSyncAppPool.
After you identify the problem users and devices, do one of the following:
Disable the synchronization of the Contacts folder on the device.
Block the problem devices at the firewall by using the User-Agent string.
Block users on a per-user basis.
Reduce the number of contacts in the Contact folder for a user.
Recycle the ActiveSync application pool every 30 minutes.
Note We do not recommend that you recycle the ActiveSync application pool every 30 minutes in a production environment.
If the server is running Exchange Server 2010, change the Throttling Policy that is applied to the user. To do this, run the following cmdlet:
The Throttling Policy can be the Default Policy or a policy that is assigned to the user.
The default value for EASPercentTimeInCAS is 100. A lower setting may be required to work around this issue. We recommend a starting value of 30. However, the most effective setting depends on the environment. We recommend that you thoroughly test each setting. If the EASPercentTimeInCAS value is incorrect, the devices that are causing the issue may be affected.
If you cannot identify the user or device that is causing the high CPU usage, collect a set of hang dump files, and then contact Microsoft Commercial Technical Support (CTS). CTS examines the hang dump files and troubleshoots the issue. To collect a set of hang dump files, follow these steps:
Download and install the ProcDump utility. For more information about the ProcDump utility, visit the following TechNet website:
When the issue that is described in the "Symptoms" section occurs, the mobile device sends the synchronization request again after several minutes if a response is not received. This can cause multiple threads that are trying to synchronize the same set of contacts. The CAS server may not finish any of the requests.
When a request is dropped because the request takes longer than the IIS time-out to complete, an error message is displayed in the HTTP API error log. This error message resembles the following: