As Microsoft license the Exchange ActiveSync (EAS) protocol to an ever wider range of device and software manufacturers, it is important to understand how the technology operates and what to check when it doesn't work.

Exchange ActiveSync is the Microsoft protocol that enables the remote push-based bi-directional synchronisation of user mailbox data, including email, contacts, calendar and task information over the air.
Device management features are also a feature of the protocol, enabling the application of corporate device usage policies, including password enforcement, remote device kill, application blacklisting, as well as the ability to remotely disable hardware and software elements on the client device.
EAS is a standard, the extent to which the capabilities of the standard are included on specific devices is at the discretion or ability of the device manufacturer.

Because EAS is a standard protocol, the same troubleshooting procedures can be applied to all devices. Although this article will focus on Windows Mobile devices, there are setup guides for a wide range of other platforms and devices available in the blog which I shall link to.

Infrastructure

EAS operates by establishing a direct connection from the mobile device to the Exchange server over the Internet. This therefore requires that the Exchange server be "Internet-facing". This may sound obvious but is not always appreciated. If companies use a mail relay service provider, such as Messagelabs, and configure their firewall to only allow SMTP traffic to Exchange from the range of addresses published by the relay provider, then to enable EAS functionality, client devices will need to be able to access the Exchange server directly.

Client devices access a web application running in IIS on the Exchange server. This requires that the Outlook Web Access (OWA) component of Exchange be enabled and correctly configured.
As it is a web application, clients will access Exchange on either TCP port 80 (HTTP) or 443 (SSL). This port will need to be open on the firewall.

Although Exchange supports both HTTP and HTTPS access, you would normally only use HTTP if a separate security measure had first been implemented, such as a VPN connection. HTTPS does add a layer of security, but does bring further complexity that needs to be taken into account when troubleshooting connection issues which I will look at in a moment.

Access does not necessarily need to be granted to the mailbox server itself, or all mailbox servers in the organisation; a front-end or client-access server can be deployed to process incoming requests, authenticate them, and route them to the appropriate back-end mailbox server. This approach, if you can afford a separate Exchange server, whilst having the benefit of exposing only one machine to the Internet, also means that regardless of where the user's physical mailbox is located globally, all users (and administrators) need only know the address of this single server. User mailboxes will be located via Active Directory and requests passed internally over the company's internal LAN/WAN links.

Client Setup

Regardless of the client device being used, the ActiveSync protocol used to access Exchange will require the same information to be able to connect and authenticate. Different devices have the ability to determine some or all of this information themselves using Microsoft's autodiscover technologies, but it is important to know what this information should be when verifying account credentials, in case the automatic setup wizard gets it wrong, or should you need it enter it manually.
The information required will include:

• Username
• Password
• Domain
• Server Address

Username, password and domain information will be the user's individual Active Directory credentials. If users have Windows-based PCs in the office, when logging in it is the content of these fields (Username, Password, Log Into) that is required.

The server address will be the OWA address of the Exchange server, normally in the form 'mail.domain.com'
There is no need to include any further suffix ('/exchange' for 2003 or '/owa' for 2007 and 2010).

Configuring a Windows Mobile Pocket PC device

From the Today Screen, tap and Start and select Programs.

From the list of available programs, launch ActiveSync. The following screen will be displayed:

Select the option to set up your device to sync with an Exchange Server. The following screen will be displayed:

You will be prompted to enter your email address, from which the wizard will attempt to determine the correct server settings to use automatically (if your PDA is running version 6.1 of the Windows Mobile software ot later), I will look at this process in more detail later. If you know the correct settings to use, untick the option to ‘Attempt to determine Exchange Server settings automatically’ and tap Next. The following screen will be displayed:

Enter the address of the Exchange Server. This will be the same address used by Outlook Web Access (OWA) – if you check your mail via a web browser ever, this will be the address to use. If you don’t know the address to use, your network administrator will be able to tell you.

Usually you should use leave the option to use an SSL connection ticked, unless specifically told by your network administrator. Tap Next, the following screen will be displayed:

Enter your username, password and domain details. These details will be the same that you use to log into your desktop or laptop PC in the office, if you have one. Again, if you don’t know the details, your network administrator will give you the correct settings to use. Tap Next, the following screen will be displayed:

Select the folders in your mailbox that you want to synchronise and click Finish.

Configuring Nokia Symbian S60 devices

Setting up the Nokia E71 - http://blog.brightpointuk.co.uk/setting-mail-exchange-nokia-e71
Setting up the Nokia E75 - http://blog.brightpointuk.co.uk/setting-mail-exchange-nokia-e75
Setting up the Nokia E52 - http://blog.brightpointuk.co.uk/setting-mail-exchange-nokia-e52
Setting up the Nokia N97 - http://blog.brightpointuk.co.uk/setting-mail-exchange-nokia-n97

Configuring HTC Android devices

Setting up the HTC Hero / Tattoo - http://blog.brightpointuk.co.uk/setting-microsoft-exchange-synchronisati...

Configuring the Apple iPhone

http://blog.brightpointuk.co.uk/setting-server-activesync-apple-iphone

Configuring Exchange 2003 SP2

By default, EAS functionality is enabled automatically when SP2 for Exchange 2003 is installed. The functionality is enabled and disabled within the Exchange System Manager:

Expand the Global Settings and open the properties for Mobile Services. Ensure that the option to Ensure Direct Push over HTTP(s) is enabled.

Configuring Exchange 2007 / 2010

On a server running Exchange 2007 / 2010, EAS is configured as a mailbox policy. Launch the Exchange Management Console. Expand the Organisation Configuration container and select the Client Access folder. Select the option to create a New Exchange ActiveSync Mailbox Policy:

Configure the settings as desired.

The newly configured profile can then be assigned to individual users or groups. Within the Exchange Management Console, expand the Recipient Configuration container and select the Mailbox folder. Open the properties of a user’s mailbox and click on the Mailbox Features tab. Ensure that the Exchange ActiveSync feature is enabled.

Multiple policies can be created as desired.

Troubleshooting

Connection Issues

If you receive an error message that the device was not able to contact the Exchange server, firstly verify that the device has a connection to the Internet - it is important to check the basics before wading too deep into the mechanics of the Exchange back-end configuration.
Verify that the user's device is correctly connected to the cellular provider, WiFi network or connected to a host PC via either Bluetooth, infrared or USB using the appropriate connection software depending on the device.
The simplest way to ensure this is to open a browser and verify they can access a site such as http://www.bbc.co.uk

Should the device appear to have a connection to the Internet, but not be able to access either the Exchange server or a public site such as the BBC, it may be an issue with DNS. Verify whether the device can connect to the BBC web site by entering the IP address rather than the friendly name - http://212.58.251.195

Should DNS be identified as the issue, then this will need to be resolved by entering in appropriate DNS servers manually into the client device - appropriate for your Internet service provider, be it a cellular provider or a WiFi connection. Entering in the IP address of the Exchange server instead of the friendly name will not resolve the issue if an SSL certificate is used on the Exchange server, as I will look at in a moment.

Should the device have a connection to the Internet, but not be able to connect to the Exchange server, verify that the server address has been entered correctly - again this should be the address used to access Outlook Web Access (OWA).

Should the address be entered correctly, and the device have a connection to the Internet, verify that the OWA address is indeed available - this can be done by browsing to the OWA address in the browser on the client itself, or from a PC connected to the Internet. Should the site not be accessible, verify whether it is available from a PC on the LAN. If not, then there is a problem with the Exchange server that needs to be investigated - try restarting the IIS service.
If the site is accessible internally via the LAN but not externally, it may be a firewall issue - verify that the correct port is open to the Exchange server from the Internet.

SSL Certificate Issues

SSL certificates are used to guarantee the identity of servers to clients. A server's identity (ie its name) is 'proven' by assigning a certificate to it that comprises a digital hash value calculated by running the server's name through a complex algorithm. When requesting content from a server, the server presents its certificate, containing the hash value. Should the requesting client perform a calculation on that hash value and come up with anything other than the expected server name, the connection is flagged as insecure. That is a massive simplification, but you get the idea. In order to be able to perform the calculation, the requesting server needs to be able to access the algorithm. If the server was assigned a root-trusted certificate, (by providers such as VeriSign, or Thawte), that algorithm is preinstalled on the device already by virtue of the fact that it already possesses the CA's 'root' certificate.

It is possible to generate a self-signed certificate using Microsoft's Certificate Services, or any other internal CA for that matter such as OpenSSL running on a Linux-based CA server and assign that certificate to Exchange. However, when using a self-signed certificate, your CA is not automatically trusted by the client device, so your root CA certificate needs to be installed onto devices manually before any certificates issued by that CA can be trusted. In a nutshell, in order to be able to trust a certificate, the root certificate of the CA that issued that certificate needs to be installed on the device.

Using self-issued certificates is normally a cost-saving measure: root-trusted certificates cost money and need to be regularly updated. But they can also offer a line of security purely based on the fact that some devices will not connect to servers that they do not trust - meaning that the administrator can control which devices have access by only installing the appropriate cert onto those devices they want to connect.
This only applies to certain devices, including Windows Mobile and Nokia Mail for Exchange clients: Android devices will warn the user about the nature of the certificate, but also offer an option to 'Continue Anyway'.

This approach does require increased administrative work, in that certificates needs to be installed onto devices manually either by connecting them to a PC and copying the certificate file across, or making the certificate available on a web server for download via a browser, and then installing locally, so as a cost-saving measure this increased workload need be considered.

If when creating an EAS connection an error is returned about the certificate being invalid, first verify that the time and date on the device is set correctly, as certificates, even root-trusted certificates, are only valid within a specific date range.

If the date and time on the device is correct, verify that the certificate assigned to the Exchange server is still valid - it may have expired and need to be re-generated.

If you receive an error message that the certificate is not trusted by the device then this would indicate that the root certificate of the CA needs to be installed manually.

If you don't know whether a certificate is self-issued or not, browse to the address of the Exchange OWA site from a PC web browser (preferably not one on the LAN). If the certificate is not root-trusted you will receive an error message in your web browser:

Internet Explorer

Safari

To export the certificate from the CA, on the Certificate Authority that issued the certificate to the Exchange server, open the Control Panel and double click Internet Options. NOTE - this step assumes that you are using a Microsoft CA.

Click on the Content tab and then on the Certificates button. Click on the Trusted Root Certification Authorities tab:

Locate the trusted root certificate for your domain. Select the certificate and click on the Export button.

The Export Certificate Wizard will be displayed, click Next:

Select the option to export the certificate in DER encoded binary X.509 (.CER) format and click Next.

Enter a name for the certificate and specify where you would like the file saved. Click Next, Finish and then OK.

If you don't know how to locate and isolate the root SSL certificate, Microsoft have released a tool to help, called the SSL Chain Saver - http://blogs.msdn.com/windowsmobile/archive/2008/05/18/sslchainsaver-v2-...
Install this tool on a machine on the LAN, or on the Exchange server itself. Open a Command Prompt and browse to the location of the executable created in the Program Files folder.
Issue the command:

sslchainsaver mail.domain.com

(where "mail.domain.com" is the address of the Exchange server to be queried)

This will create a directory called "mail.domain.com" including the certificate of the root CA in a file named "root.cer" as well as a log file containing details of all the CAs passed on the route to the root CA.
Copy this file to the client device and install it following the procedure appropriate for the device - in most cases this consists of copying it to the device from a PC, browsing to it on the device itself using the built-in file manager application and selecting it, then following the on-screen prompts.

If you receive an error message on the client device that the SSL certificate is trusted, but that the name of the server trying to be reached does not match the name that the certificate was issued to, then this would indicate that when the certificate was first requested for the server, the incorrect details were entered in the certificate request.
This is not so much of an issue if the certificate assigned to the Exchange server is a global "*.domain.com" certificate applied to all web servers within a company, but if a specific certificate is being issued for the Exchange server then the request needs to contain the external 'web' name of the server, NOT the internal or NETBIOS name of the server. By that I mean, if clients are going to be connecting to 'mail.domain.com', then the certificate generated should identify this name, NOT just 'exchange' or 'exchange.internal.local'
This also means that if a certificate is generated for 'mail.domain.com', you will not be able to enter the external IP address of the Exchange server in the client either.

Authentication Issues

These issues tend to apply only to Exchange 2003 specifically, not SBS2003 or later version of Exchange, and only to Windows Mobile clients.

Should you know that the credentials supplied are correct, and you are able to log into OWA from a browser using the same credentials, but you are not able to authenticate successfully from a client device, then the authentication settings on the Exchange OWA web site may need to be altered to enable Windows Mobile devices to connect successfully.

On an Exchange 2003 "front-end / back-end" deployment, verify that "Integrated Windows Authentication" is enabled on the Exchange web site within IIS Manager on the back end Exchange server - it won't be by default.

On a single-server Exchange 2003 deployment, there are a number of areas to investigate.
The first of these is Forms-based authentication (FBA).

FBA is enabled by default on Exchange 2003 OWA installations and can prevent Windows Mobile clients from authenticating. You will know if this is the issue as clients will simply refuse to authenticate, constantly prompting you for the user password, despite the password being correct.
You will know if FBA is enabled, as when accessing OWA from a web browser, you will see the following:

If FBA is not enabled, when browsing to the OWA site you will simply receive a prompt asking for a username and password, as with when mapping network drives:

FBA is enabled and disabled within the Exchange System Manager, rather than within IIS. Browse to the Exchange Server --> Protocols --> HTTP and open the properties of the virtual Exchange HTTP Server:

Disable forms-based authentication, save the changes and then restart the IIS service on the Exchange server.

If this does not resolve the problem, or having disabled FBA you now receive a different error along the lines of "you do not have permission to access this resource", then it may be necessary to create a new virtual IIS directory on the Exchange 2003 server and allocate specific permissions to that new directory, distinct from the Exchange default web site.

If disabling FBA did resolve the problem, but you specifically want FBA enabled for OWA PC-based users, then creating a new IIS directory would also address this requirement.
This is a formal Microsoft resolution and effectively involves creating a new IIS directory, adjusting the authentication settings on that specific site, restricting access to the new site to the IP address of the Exchange server itself, and then editing the registry on the Exchange server to 'tell' Exchange to use this new site for EAS service.

This is acceptable from a security perspective as correctly authenticated requests will be received by the default web site. The web site will then detect from the headers in the client HTTP request that the request is intended for the ActiveSync web application. This request will then be passed to the ActiveSync application in only basic authentication, but from the Exchange server itself. Confused? The procedure to configure this is as follows:

Temporarily disable FBA within the Exchange System Manager, save the changes and restart the IIS service.

Launch the IIS Manager. Right click on the Exchange folder and select All Tasks → Save Configuration to a file:

Enter a name for the file, such as ‘ExchangeVDir’ and click OK:

Right click on the Default Web Site folder and select New → Virtual Directory from File:

Click on the option to Browse, then select the ExchangeVDir.xml file you just created.
Click on Read File.
Select Exchange as the Location and click OK:

You will receive a warning that the name already exists, select the option to enter a new Alias and name it ‘Exchange-OMA’:

Click OK.

The new Exchange-OMA folder will now be listed. Right click on it and select Properties.
Click on the Directory Security tab. Within the Authentication and Access Control section click the Edit button. Ensure that only the following options are enabled:

Click OK. In the IP address and domain name restrictions section, click the Edit button:

Select the option to Deny access to all computers, then Add the IP address of the Exchange server. Click OK.

In the Secure Communications section, click the Edit button. Untick the option to require SSL if ticked:

Click OK and then OK again.

Now re-enable FBA within the Exchange System Manager again (if required) and restart the IIS service again.

Edit the Registry

Now open Registry Editor on the Exchange Server. Browse to the following folder:

HKEY_Local_Machine\System\CurrentControlSet\Services\MasSync\Parameters

In the right hand pane, right click and select New → String Value. Enter a name of ExchangeVDir for the new string. Double click the entry to edit it:

In the Value data field, enter the name of the Virtual Directory you created earlier. Click OK.

Close Registry Editor.

Restart IIS

Open the Services snap-in and restart the IIS Admin service on the Exchange server. Select Yes to also restart all dependent services.

Once IIS has been restarted, close the Services snap-in.

You should now, hopefully, be able to correctly authenticate from your Windows Mobile client device.

Troubleshooting Tools

A variety of tools are available on the Internet to impersonate an ActiveSync client and produce a report on accessibility and any errors encountered when accessing an Exchange server, the best of these I have come across is that offered by AccessMyLAN- https://store.accessmylan.com/main/promo-testtool

Microsoft AutoDiscovery

Exchange 2007 introduced a new feature called "AutoDiscovery" which simplifies the client setup procedure by enabling devices to correctly determine the Exchange server address to use based on the user's email address.
This requires that the administrator create a DNS CName alias record for 'autodiscover.domain.com' which maps to 'mail.domain.com' (where mail.domain.com is the address of the CAS server).
This service is principally intended for Outlook 2007 clients, but can be utilised by mobile devices.
By entering in your email address, the ActiveSync client performs a lookup on the domain entered in the email address and searches for 'autodiscover.domain.com'. If it finds a record, it uses this as the server address. This still requires that you enter in your username, password and domain credentials manually, but it removes the need to know the server address.
For Outlook clients on PCs, the fact that you have already logged into the domain means that this information can be ascertained automatically.

To configure AutoDiscover functionality on an Exchange 2007 / 2010 CAS server, issue this command at the Powershell prompt:

Set-ActiveSyncVirtualDirectory -Identity "COMPUTERNAME\Microsoft-Server-ActiveSync (Default Web Site)"
 -ExternalURL "https://servername.com/"