HTTP 500 on Microsoft-Server-ActiveSync: every mobile device stops syncing

Fix it now

When every phone stops syncing within the same few minutes, the phones are not the problem. HTTP 500 means the ActiveSync application ran and threw; HTTP 503 means nothing was there to take the request, which is normally a stopped or rapid-failed application pool. Both are fixed on the server, and devices resume on their own.

Get-WebAppPoolState MSExchangeSyncAppPool
Start-WebAppPool MSExchangeSyncAppPool
Get-ActiveSyncVirtualDirectory | Format-List Server,InternalUrl,ExternalUrl
Get-MailboxDatabaseCopyStatus *
Test-ServiceHealth

1. Browse to https://<your namespace>/Microsoft-Server-ActiveSync from the server itself. An authentication prompt is healthy; an immediate 503 means the application pool is not running.
2. Start the sync pool and watch whether it stays up for five minutes. A pool that stops again is crashing, and rapid-fail protection will then answer 503 to everything.
3. Check free disk space on every Exchange volume. A full logging or transport volume takes application pools down before it takes anything else down.
4. If devices are looping rather than failing, look for HTTP 449 in the IIS log: that is provisioning, not an outage, and the fix is in the mobile device mailbox policy.
5. Read the MSExchange ActiveSync entries in the Application log around the failure and work from their text rather than from the event number.

Do not tell users to remove and re-add their accounts while the server is broken. It creates a fresh partnership per device, a burst of full resynchronisation when the server recovers, and a pile of stale partnerships to clean up.

If devices start syncing again, stop here. If they do not, the next section follows a request through the server and shows where each status is produced.

Why it happens

A device connects to the ActiveSync path on the Default Web Site, authenticates there, and the front end proxies the request over HTTPS to the Exchange Back End site on the server holding the active copy of that mailbox’s database. Any hop can fail, but the device only ever sees the status the front end hands back, which is why a dismounted database and a broken IIS configuration look identical from a phone.

503 and 500 separate two very different situations. Microsoft’s published description of 503 is that the server is temporarily unable to handle the request; on an Exchange server that means the request could not be handed to an application at all, because the pool is stopped or IIS has shut it down under rapid-fail protection after repeated worker crashes. 500 is published as the server encountering an unexpected condition that prevented it from fulfilling the request: the application took the request and then failed.

HTTP 449 is not an error. The Exchange ActiveSync protocol documentation states that when protocol version 2.5, 12.0 or 12.1 is in use, a 449 is returned in place of status 140 RemoteWipeRequested, 141 LegacyDeviceOnStrictPolicy, 142 DeviceNotProvisioned, 143 PolicyRefresh or 144 InvalidPolicyKey. Every one of those is a provisioning or policy condition, so a device looping on 449 has a policy it cannot satisfy rather than a server that is down.

The codes the device shows are coarser than the ones in the IIS log, but Microsoft does publish them. 0x85010014 maps to E_HTTP_SERVER_ERROR with the user-facing text “Can’t connect to the server”. 0x85010004 maps to E_HTTP_FORBIDDEN – “Can’t connect to the server right now. Wait a while and try again, or check the account’s settings.” That second one matters: it is a 403 from the server, not a network failure, so it sends you to device access rules and the mailbox’s ActiveSync state rather than to the firewall.

Full reference

Sorting the symptom before touching the server

Where each status is produced

The device-side codes Microsoft publishes

Microsoft’s guidance for both is to verify the server name first. For the forbidden case it adds a second check that is easy to miss: where the account uses certificate-based authentication, confirm the certificate is still valid and replace it if not. That is a genuinely different investigation from a 500, and the two codes are one digit apart.

Testing the endpoint properly

• Test-ActiveSyncConnectivity is the Exchange cmdlet for this, and it takes -ClientAccessServer, -URL or -MailboxCredential for a single mailbox. Microsoft’s own reference notes that it works best on Exchange 2010 and that Managed Availability supersedes it on later versions, recommending Invoke-MonitoringProbe instead, so treat a clean result as one data point.
• The Microsoft Remote Connectivity Analyzer tests from outside your network, which is the only way to see what a device on a mobile network sees.
• Get-MobileDeviceStatistics -Mailbox <user> tells you when a real device last synced successfully, which is more honest than a synthetic test.
• Reading the IIS log directly and filtering the sc-status column for anything other than 200 remains the fastest way to see the pattern across all devices at once.

The event with no published description

Event ID 1008 from the MSExchange ActiveSync source turns up around these failures and Microsoft publishes no description for it. Read the entry rather than the number: the description field carries the component and the exception, which is what you need. Be wary of search results for “Event ID 1008” in particular, because a Perflib event with the same number and a completely different meaning dominates them.

When it is one mailbox rather than the server

• Check the mailbox’s own ActiveSync state: Get-CASMailbox <user> | Format-List ActiveSyncEnabled,ActiveSyncBlockedDeviceIDs,ActiveSyncMailboxPolicy.
• Check whether a device access rule or the organisation’s default access level is quarantining the device family.
• Check whether the mailbox has accumulated a large number of stale device partnerships, and remove the ones for devices that no longer exist.
• Check the user’s Active Directory object for the permission problem that produces Event ID 1053, which is a different article and a different fix.
• Only then move the mailbox, which is a large hammer for a problem that is usually a permission or a policy.

Every code this article covers

Confirm the fix worked

1. Browsing the ActiveSync path from the server returns an authentication prompt rather than an error page.
2. The sync application pool is running and is still running an hour later.
3. Get-MobileDeviceStatistics -Mailbox <user> shows a recent successful sync for a real device.
4. The IIS log for the ActiveSync path shows 200 responses rather than 500, 503 or repeating 449.
5. A second mailbox on a different database syncs as well, which rules out a single database.

Questions people ask about this