Posts Tagged ‘MobileIron’

Exchange Activesync Issue: Device is able to authenticate, however it will not sync.

In Exchange, IOS, Server Activesync on October 26, 2011 at 11:31

We have recently taken our solution for Exchange email on IOS devices into production. We are using client certificate authentication on TMG and we use MobileIron to manage the devices and handle the certificate enrollment on the devices.

We had an issue where our root CA’s crl had expired, which as could be expected led to a situation where no one could sync their email. After tackling that problem one user was still not able to sync. That user had been part of the pilot group so we first cleaned up the certficate clutter for that user account, but he was still not able to sync.

As I mentioned before, we use client certificate authentication on TMG, but no delegation to our CAS servers. And since the authentication on TMG worked as expected for that user we decided to examine the logs on the CAS server.

In IIS logs the following error was logged:

2011-10-25 13:29:25 W3SVC1 *.*.*.* POST /Microsoft-Server-ActiveSync/default.eas User=hartj&DeviceId=Appl*********&DeviceType=iPhone&Cmd=SendMail&SaveInSent=T&Log=V121_LdapC0_LdapL0_RpcC9_RpcL15_Ers1_Pk0_Error:DeviceIsBlockedForThisUser_ 443 *******\[USERNAME] *.*.*.* Apple-iPhone3C1/901.334 403 0 0
This confirmed that the authentication worked, because otherwise the device would not be able to get to the CAS server in the first place. So we turned to Google 🙂 This led us to this excellent article on the german site EAS Authentizirung
This article described blocking access to Activesync based on IMEI or device ID. When the device id is not present in the ActivesyncAllowedDeviceIDs attribute the DeviceIsBlockedForThisUser is logged in the IIS logs and in tthe event viewer:
The article on blocking devices also showed us how to fix this issue – we manually added the DeviceID to the user using the set-casmailbox command:
Set-CasMailbox [USER] –ActiveSyncAllowedDeviceIDs [DEVICEID].
We still have no clue why this happened – either something went wrong while we were troubleshooting the certificate issues or somehow the device partnership was corrupt ( even though we had deleted that manually before with no result).