Windows : Exchange 2013 ActiveSync unable to verify account information

By | November 10, 2013
0 Comment

Having issue connecting mobile devices to your new Exchange 2013 server and get “unable to verify account information” error message? Well there is several possible causes, however I find out that Windows Authentication is disabled by default in IIS and is the root cause if the issue with Exchange 2013.

First, make sure the external URL to access ActiveSync service is set properly. Open up the Exchange management shell console and type the following command :

Get-ActiveSyncVirtualDirectory | fl name,*url*

You should expect the following output :

[PS] C:\Users\user\Desktop>Get-ActiveSyncVirtualDirectory | fl name,*url*

Name : Microsoft-Server-ActiveSync (Default Web Site)
MobileClientCertificateAuthorityURL :
InternalUrl : https://mail.domain.tld/Microsoft-Server-ActiveSync
ExternalUrl : https://mail.domain.tld/Microsoft-Server-ActiveSync

If everything above is good, just continue with the following steps. Let’s see what’s in the IIS HTTP logs for the default VHost…

Browse to :

C:\inetpub\logs\LogFiles\W3SVC1

Open the most recent log file. Then search for your mobile device IP address… you will probably find something similar to this :

2013-11-09 19:36:15 0.0.0.0 OPTIONS /Microsoft-Server-ActiveSync/default.eas - 443 user@domain.tld 0.0.0.0 Apple-iPhone5S/1002.329 - 401 1 1326 31

Well, as we can see at the end of the previous log entry, the request end up with a “401 access denied” code. This is definitely an authentication issue!

By default, the only enabled authentication mechanism is “Basic Authentication” and “Windows Authentication” is disabled. This is exactly why you can’t authenticate with ActiveSync!

1. Open the IIS management console

2. Click on “Default Web Site”

3. Go to IIS/Authentication

4. Click on “Windows Authentication” and then click “Enable” on the right Action panel.

5. Do the same for “Exchange Back End” VHost.

6. Restart IIS

ActiveSync should work now and if you research the latest entries in the IIS log file, you should see the same entry as mentioned previously but followed with a “200 OK” code.