Exchange 2003 – Windows Mobile Sync Error Code 85010014 – Exchange 2003 Only
NOTE: This page is referring to code 85010014 received when trying to sync over the air with an Exchange 2003 server. It does NOT refer to the error received when trying to sync with the desktop ActiveSync.
A common error when trying to setup a Windows Mobile 5.0 device to sync with Exchange 2003 is 85010014. This is generic error that can actually mean a number of things. There are a number of standard tests and best practises that you can carry out to resolve the error.
If you are working on this problem then you may want to look at getting the emulator, so that you can reset the device as much as you like. This also works inside your network, so you avoid any firewall issues. However it does mean that care has to be taken over the address format used when setting up the connection on the emulator.
- First and foremost, does Outlook Mobile Access (OMA) work?
EAS and OMA share some of the same core functionality. In most cases if one works, so will the other. It is also easier to see error messages in Internet Explorer/Pocket Internet Explorer than in ActiveSync, which often gives a cryptic error message and not much else.
OMA can be tested on both Internet Explorer on the device and on your desktop.
Browse to http://host.example.com/oma (where host.example.com is the external name of your server) and see if the application loads correctly. If you get an error, particularly one about requiring SSL, then that can cause a problem.
- Is your SSL certificate trusted by the Windows Mobile device?
If you are using a home grown certificate then then answer will be no. You can test this by browsing to the https version of OMA using the same URL as above – https://host.example.com/oma and see if you get an SSL certificate prompt. The prompt will tell you what element the process is failing on.
If you are using a home grown certificate then your best option is to switch to a certificate that is trusted by Windows Mobile 5.0. Certificates from GoDaddy are trusted and cost from US$29.99. You can get one from https://CertificatesForExchange.com/ . By using a trusted certificate you will have nothing to install on the device. The certificate is also good for OWA, RPC over HTTPS and securing anything else on the web site.
If you already own an SSL certificate, but it is not trusted by Windows Mobile, then you will need to import the root certificate. Instructions for doing that are elsewhere on this site.
- Are you entering the address correctly?
When entering the address in to ActiveSync, it should be just the fully qualified domain name – so host.example.com. No / anything or http in the address. It is also not recommended to use an IP address. Instead setup a split DNS system so that the FQDN works both inside and outside, but resolves to different IP addresses depending on where the device is connected.
- Are you using SSL, possibly with Forms Based Authentication on a single Exchange server?
The combination of SSL and Forms Based Authentication is the biggest cause of these errors.
Microsoft have a resolution in their KB article 817379, however this article misses out some key steps which we have found to be required and are outlined below.
Setting up Exchange 2003 for Forms Based Authentication, SSL and Windows Mobile Exchange ActiveSync.
These instructions are based on 817379 with some slight adjustments.
- In Exchange System Manager, Servers, , Protocols, HTTP. Right click on the Exchange virtual server and choose Properties. Click on the tab “Settings” and disable forms based authentication.
- In IIS Manager, remove the SSL certificate from the default web site
- Still in IIS Manager, remove the “Require SSL setting from all virtual directories, particularly, /exchange, /exchweb, /Microsoft-Server-ActiveSync and /oma.
- Drop in to a command prompt and type iisreset and press enter.
- Go back in to IIS manager, and find right click on the Exchange virtual directory, choose All Tasks, and then Save Configuration to a File.
- In the File name box, type a name. To follow Microsoft’s example, type “ExchangeVDir” and then click OK.
- Right click on the root of the Default Web and choose New, then “Virtual Directory (from file)”.
- In the Import Configuration dialog box, click Browse and locate the file that you created earlier. Choose Open, then Read File.
- Under “Select a configuration to import”, choose Exchange, and then choose OK. You will get a dialogue box appear that states the “virtual directory already exists.” The option to create a new virtual directory should already be selected. In the box enter an new name. To follow Microsoft’s example, enter “exchange-oma” and choose Ok. The new folder should be created.
- Right click on this new virtual directory and choose Properties. Then click on the “Directory Security” tab.
- Under “Authentication and access control”, click the Edit button. Ensure that only “Integrated Windows authentication” and “Basic authentication” are enabled. Change it if required. You need to ensure that Anonymous authentication is not enabled. Leave the Default domain and default realm blank. Press OK to go back to the main properties of the virtual directory.
- Under “Secure communications”, click the Edit button. Make sure that “Require secure channel (SSL)” is not enabled, and then click OK.
- Drop in to a command prompt and run iisreset again.
- Copy and paste the following registry entry in to a new notepad document and then save it as ExchangeVdir.reg. Then right click on it and choose Merge.
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMasSyncParameters]”ExchangeVDir”=”/exchange-oma”
- After making the change, run iisreset again, then restart the IISADMIN service in Services.
- Put the SSL certificate back on the site, but do NOT set the require SSL option at this time.
- Test the sync process to prove that it works.
- If sync works, re-enable forms based authentication in Exchange System Manager.
- Once testing is confirmed to have worked, place IP address restrictions on the /exchange-oma virtual directory to restrict access to the server itself. You should also include 127.0.0.1. This ensures that the exchange-oma virtual directory isn’t used to bypass the forms based authentication page. It isn’t a requirement to make the change, the security of the server is not compromised and it is unlikely that users would find the directory and use it. You may also find the /exchange-oma virtual directory useful if you want to publish OWA web parts in SharePoint internally.
Q: Why do I need to keep running iisreset? What does it do?
A: IISRESET writes the current IIS configuration to the IIS metabase. In testing we found that running iisreset after making changes to the IIS configuration produced the best results. It does not change any settings that have already been made.
Q: Why do you include the additional steps at the beginning?
A: The import/export process brings across all of the settings on the virtual directory – including the ones that cause problems – the SSL, forms based authentication etc. By turning those options off and then running iisreset before starting the import/export process, you ensure that you don’t bring any settings that are not required.
Q: I want to use SSL, but I cannot if I remove the setting to require SSL.
A: Don’t confuse the Require SSL setting with your ability to use SSL. You can have use SSL without requiring it. The reason that you have to remove the require SSL setting is because EAS/OMA make internal calls on the /exchange virtual directory on port 80. Require SSL breaks that functionality.
However once this setting has been configured and is working, you can put require SSL back on to the /exchange virtual directory.
From a security point of view though, your best option is to simply block port 80 at the firewall and only allow port 443 through. While this may annoy some users who have to correct the URL, it keeps anonymous http traffic off the network.
Q: I have already tried 817379 and it didn’t work. What now?
A: If you have already tried to follow the instructions in 817379 then you need to reset everything back to the default.
Remove the registry key first from the location stated above (HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMasSyncParameters), then reset the virtual directories following the instruction in this article: http://support.microsoft.com/kb/883380.You should be using Method 1 – which is the easiest to do. Then follow the instructions above.