Samsung Galaxy SII: Security update required for syncing with Office 365

So your phone has been syncing your mail, calendar and contacts with Office 365 (Exchange Online) for months without problems when everything suddenly comes to a halt.

No recent changes have been made to your phone or the Office 365 domain. Existing email on your phone are unavailable due to the error: “unable to open server connection due to a security update”. If so, then welcome to the party.

Scouring the Office 365 support forum for answers is not really helpful as the general conclusion given by the support staff is that the phones are misconfigured, blindly ignoring the fact that a device that has not been changed and was previously working, is probably not misconfigured.

To resolve the problem I tried removing (including deleting the local email and Exchange app data) and re-adding the account on the phone which worked for a couple of hours before the “Security update required” message brought everything back to a sudden halt. Removing the associated phone from OWA (Outlook Web Application) before adding the account back didn’t make a difference either.

So what does this “Security update required” message mean and how is your phone supposed to handle it?
The Exchange Server Interoperability Guidance does in short state the following:

Microsoft Exchange ActiveSync policy settings are the primary tool that manage devices that connect to Microsoft Exchange mailboxes. Policy settings define the terms by which a client can synchronize mailbox data. The provisioning process is a communication between client and server that indicates whether the client can enforce the required policy settings.

The client’s goal in provisioning is to obtain a policy key from the Exchange server. The policy key enables the client to synchronize with a mailbox. Provisioning involves the following steps:

Client and server exchange policy information:

The client submits a Provision command request to the server. The request includes information that identifies the client and specifies the policy format that the client wants the server to use. The server responds with a Provision command response that contains policy settings that the client must enforce, and a temporary policy key.

Client acknowledges/applies policy settings and server provides policy key:

The client submits a Provision command request to the server to indicate its ability to enforce the security policy. If the Provision command request indicates that the client can apply the security policy settings, the server responds with a Provision command response that contains a policy key that the client can use in subsequent requests to synchronize mailbox data.

With a basic understanding of how Exchange ActiveSync (EAS) works, I decided to activate ActiveSync logging to investigate the communication between Office 365 and my phone. Logging may be activated from the phone details screen in OWA (Outlook Web Application).

When reading the ActiveSync logs, it’s really not that hard to spot where things go wrong. The following contains some heavy edited parts from the logs (keys have been changed for privacy). The term “client” refers to the default android e-mail application for the Galaxy S2 phone.

The invalid policy key:

RequestHeader : 
POST /Microsoft-Server-ActiveSync/default.eas?Cmd=Sync&User=user%40domain.tld&
DeviceId=SAMSUNGSECTRET&DeviceType=SAMSUNGGTI9100 HTTP/1.1 
<snip/> 
User-Agent: SAMSUNG-GT-I9100/100.40003 
X-ExCompId: AirSync 
MS-ASProtocolVersion: 14.1 
X-MS-PolicyKey: 0 
<snip/> 
AccessState : Blocked 
AccessStateReason : Policy

ResponseBody : 
<?xml version="1.0" encoding="utf-8" ?> 
<Sync xmlns="AirSync:"> 
        <Status>144</Status> 
</Sync>

The X-MS-PolicyKey header indicates that there is a policy in place but the device needs to provision. The response status code 144 says that the policy key sent by the client is no longer valid. This occurs when the policy is changed on the server (a new policy key is generated every time the policy changes). The client has to resend the provision command request to get the new policy.

Mr. Android, do you speak EAS?

RequestBody : 
<?xml version="1.0" encoding="utf-8" ?> 
<Provision xmlns="Provision:"> 
	<DeviceInformation xmlns="Settings:"> 
		<Set> 
			<Model>GT-I9100</Model> 
			<snip/>
			<FriendlyName>GT-I9100</FriendlyName> 
			<OS>Android</OS> 
			<OSLanguage>English</OSLanguage> 
			<snip/>
		</Set> 
	</DeviceInformation> 
	<Policies> 
		<Policy> 
			<PolicyType>MS-EAS-Provisioning-WBXML</PolicyType> 
		</Policy> 
	</Policies> 
</Provision> 

ResponseBody : 
<?xml version="1.0" encoding="utf-8" ?> 
<Provision xmlns="Provision:"> 
	<DeviceInformation xmlns="Settings:"> 
		<Status>1</Status> 
	</DeviceInformation> 
	<Status>1</Status> 
	<Policies> 
		<Policy> 
			<PolicyType>MS-EAS-Provisioning-WBXML</PolicyType> 
			<Status>1</Status> 
			<PolicyKey>2957539614</PolicyKey> 
			<Data bytes="37"/> 
		</Policy> 
	</Policies> 
</Provision>

The client correctly sends a command for provision including device details and policy type (the policy type should always be set to MS-EAS-Provisioning-WBXML).

From the response body we notice that Exchange is confirming that the request can be processed by returning the value 1 for the status element (***** of Provision). We also notice the other status element (***** of Policy) confirms that the policy settings were applied correctly, and that the Data element contains the policy settings to apply.

I’m not sure why the Data element doesn’t list any settings, but maybe it has something to do with the logging format (it looks exactly the same with a successfully completed provisioning).

The PolicyKey element contains the temporary key that should be used in the next provision request that confirms the client’s ability to enforce the security policy.

What happens next is absolutely nothing. The client doesn’t make the final provisioning request but instead sends the sync command and we’re right back where we started.

Rinse and repeat

The only time the client was able to successfully complete the provisioning was when I removed the account from the device and added it back. The client will then make the provisioning request with the temporary key and even apply the policies. This is an interactive process where you confirm each step.
However, hours (or minutes) later Exchange demands a new policy, and the client is unable to comply, as it seems android has only implemented “full provisioning” during the account setup process.

More reliable alternatives:

The third party app TouchDown was able to do what the default android email client could not, that is getting in sync with my email, calender and contacts without issues. I guess it probably has something to do with a better implementation of EAS. Other ActiveSync compatible apps are also available from Google Play.

28 Hours Later:

To see if time heals (it’s a cloud service after all)) I (once again) added my account using the standard android e-mail client. Surprisingly it now just simply works. I have not gotten any “security update required” notices since. Nor has Exchange pushed a new policy key.

Who to blame:

Google / Samsung: The EAS (Exchange ActiveSync) implementation is obviously far from good enough. From what I’ve seen, there has been a lot of reports regarding errors relating to ActiveSync. This should be the single most important feature to improve for future android releases.

Microsoft: Why does Online Exchange push a new policy when I know for a fact that nothing has been changed with our Office 365 domain. Second, the fact that a couple of days later everything worked as normal seems to point to backend issues.