Samsung Galaxy S3 Continues to Generate Security Settings Update Message (O365)

Issue:
Even after properly configuring the Office 365 account, the Samsung Galaxy S3 continues to generate the Security Settings Update message.  Properly means that the user swiped down on the notification window during configuration and enabled the device administrator service.
 
Resolution:
A review of ActiveSync logs for devices exhibiting this behavior indicates the device was constantly attempting to be re-provisioned or the server was rejecting the device's policy key and forcing a re-provision.  Microsoft suspects this may be tied to the device looking up auto-complete information in the mailbox.
 
As a workaround, remove the exchange account from the device, clear the auto-complete cache from Outlook, and then add the account back to the device.  The cache can be cleared one of two ways:
 
1.  Start Outlook with a switch - outlook.exe /CleanAutoCompleteCache
 
or
 
2.  Open Outlook, go to File > Options > Mail > Send messages - click Empty Auto-Complete List
 
 
The complete detailed explanation of why this might be happening is listed below:
 
Hi Jim,
 
Thanks for the log.  The log confirmed something for me and possibly gave us something to try.
 
Based on the symptoms with the Security Required message, it appeared as though the device was constantly asking to be re-provisioned or that the server was rejecting the device’s policy key and forcing the device to re-provision.
 
This can be seen in each log entry and finding the X-MS-PolicyKey.  A value of 0 that is sent to the server indicates a need to request and acknowledge the policy settings for the tenant and requires confirmation from the device that it can handle these settings.  After this process is complete, we generate a hash value and populate the X-MS-PolicyKey.  As long as the device requests to the server has this hash value, things should function correctly.
  
My initial investigation into this log showed me that the device was in fact sending requests to the server with a policy key of 0, which would explain the security errors the user would constantly see.  At one point, the user accepts the provisioning, and the server returns the proper hash value.  In Log Entry: 16 the device was properly passing the right hash and the server responded successfully.  In Log Entry: 17 we suddenly see the device send a new request and the policy key is it is passing is 0, so we’d be back to the security prompts.  I see this pattern repeat itself a few times in the log where we accept the provisioning on the device, get the valid policy key, and the device eventually sending a request with a policy key of 0 again.
 
With just this information, I’d have to say that we would need to continue the investigation with either the device manufacturer or the carrier because for some reason the device has decided to request to be provisioned once more.
 
I did look at a few of the logs prior to the device sending the policy key of 0.  The device is trying to perform an request and actually generates an error:
 
RequestBody :
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">
                        <Collections>
                                                <Collection>
                                                                        <SyncKey>1517411971</SyncKey>
                                                                        <CollectionId>RI</CollectionId>
                                                                        <DeletesAsMoves/>
                                                                        <WindowSize>10</WindowSize>
                                                                        <Options/>
                                                </Collection>
                        </Collections>
</Sync>
 
SyncCommand_OnExecute_Exception :
Microsoft.Exchange.AirSync.AirSyncPermanentException
   at Microsoft.Exchange.AirSync.RecipientInfoCacheSyncCollection.OpenSyncState(Boolean autoLoadFilterAndSyncKey, SyncStateStorage syncStateStorage)
   at Microsoft.Exchange.AirSync.SyncCommand.SyncTheCollection(SyncCollection collection, Boolean createSubscription, Boolean tryNullSync)
   at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()
 
LogicalRequest :
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">
                        <Collections>
                                                <Collection>
                                                                        <SyncKey>1517411971</SyncKey>
                                                                        <CollectionId>RI</CollectionId>
                                                                        <DeletesAsMoves/>
                                                                        <WindowSize>10</WindowSize>
                                                                        <Options/>
                                                </Collection>
                        </Collections>
</Sync>
 
Command_WorkerThread_Exception :
--- Exception start ---
Exception type: Microsoft.Exchange.AirSync.AirSyncPermanentException
Exception message:
Exception level: 0
HttpStatusCode: OK
AirSyncStatusCode: Search_TooComplex
XmlResponse:
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">
                        <Status>8</Status>
</Sync>
Exception stack trace:    at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()
   at Microsoft.Exchange.AirSync.SyncCommand.ExecuteCommand()
   at Microsoft.Exchange.AirSync.Command.WorkerThread()
Inner exception follows...
Exception type: Microsoft.Exchange.AirSync.AirSyncPermanentException
Exception message:
Exception level: 1
HttpStatusCode: InternalServerError
AirSyncStatusCode: ServerError
XmlResponse:
[No XmlResponse]
Exception stack trace:    at Microsoft.Exchange.AirSync.RecipientInfoCacheSyncCollection.OpenSyncState(Boolean autoLoadFilterAndSyncKey, SyncStateStorage syncStateStorage)
   at Microsoft.Exchange.AirSync.SyncCommand.SyncTheCollection(SyncCollection collection, Boolean createSubscription, Boolean tryNullSync)
   at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()
--- Exception end ---
 
I highlighted what I thought was important, first noting we were throwing a Search_TooComplex error.  But what were we looking to search?  From my search in MSDN, I found the following:
 
 
The CollectionId value "RI" specifies the recipient information cache, which is an information store that contains a list of contacts that the user has interacted with most often in the near term, and with whom the user is likely to interact again. The recipient information cache is a special folder (similar to the Inbox folder), which limits the operations that can be performed on it.
 
So it’s possible the device was trying to look up the Autocomplete information in the mailbox?  Prior to Exchange 2010, autocomplete was known as the nickname cache, or nk2 file, and this was found on the workstation.  In Exchange 2010, we moved this to be a hidden folder within the mailbox.
 
I believe the issue still lies outside of Exchange and O365 and device is not properly handling this scenario, but can we a take a shot at clearing the Autocomplete cache from the mailbox and see if the problem persists?
 
There are two ways to clear the cache:
 
1. Start Outlook with a switch – outlook.exe /CleanAutoCompleteCache
 
2. Open Outlook, go to File->Options->Mail->Send messages - click "Empty Auto-Complete List".
 
We may want to clear this cache after the device has been removed from the O365 account and cleaned up.  Once the cache is clear, attempt to reconfigure the device.
 
Regards,
 
Senior Support Escalation Engineer - Exchange Online Services
Enterprise Communications Support
 
Microsoft Corporation
 
© 2016 AppRiver LLC.  All rights reserved.

Add Feedback