This is for Exchange 2003 ONLY. For the version for Exchange 2007, click here: Troubleshooting Exchange ActiveSync - Exchange 2007
When Exchange ActiveSync (EAS) isn't working correctly, it can be a pain to troubleshoot as all you get are cryptic error codes.
The quickest way to troubleshoot EAS is to check whether Outlook Mobile Access (OMA) is working correctly. They share the same infrastructure and often if one isn't working then the other will fail as well.
You can do the initial troubleshooting on OMA with a standard web browser. Turn off "Friendly http error messages" first, so that you can see the true error.
Then browse to http://servername/oma and login using the credentials in the format of domain\username and the password.
You should get a folder list in a plain text format. If you get anything else, then it isn't working properly.
If you are using SSL, then you will need to browse to the HTTPS URL.
Major things to check...
The ActiveSync push only works over a mobile phone connection, so if you are trying to see the feature work over a wireless or wired network connection, you will not. Regular initiated sync should work over the wireless connection though.
Windows Mobile prior to version 6 is not universally compatible with wildcard SSL certificates, so if you have one of those you will need to change it for a named host certificate for maximum compatibility.
Browse to https://servername.example.com/oma where servername.example.com is the name on the certificate.
If you get a certificate prompt, then that will cause EAS to fail, as it cannot handle the certificate prompt. Ideally you should be deploying this feature with a purchased certificate, but if you do need to use a certificate that isn't trusted by one of the built in root certificates, or need to import your own root certificate, then the certificate will need to be installed on to the device.
SSL and Forms Based Authentication
Having SSL and Forms Based Authentication enabled can trigger the 85010014 sync errors. This is easily fixed, and is discussed here.
The authentication settings on the virtual directories have caught some people out.
Again these are set in IIS Manager. On each virtual directory, click on Directory Security and then Edit under "Authentication and Access Control".
/exchange: Basic ONLY. Optional: set a default domain and a default realm*
/exchweb: Anonymous ONLY.
/exadmin: Integrated ONLY.
/OMA: Basic ONLY. Optional: set a default domain and a default realm*
/Microsoft-Server-ActiveSync: Basic ONLY. Optional: set a default domain and a default realm*
* If you are using SSL, then setting the default domain and default realm has no effect on your users requirement to enter the domain name as part of their username (domain\username). You must enable forms based authentication and Exchange 2003 Service Pack 2 or higher, which has an undocumented change that defaults to not requiring the domain\ - despite what the web page says.
If the application pools aren't set correctly, then the web application doesn't run. Also in IIS Manager.
/exchange - ExchangeApplicationPool*
/exchweb - ExchangeApplicationPool*
/exadmin - ExchangeApplicationPool*
/public - ExchangeApplicationPool*
/oma - ExchangeMobileBrowseApplicationPool
/Microsoft-Server-ActiveSync - ExchangeApplicationPool
* will probably show ExchangeApplicationPool but greyed out.
Microsoft Test Site: https://testexchangeconnectivity.com