Exchange ActiveSync Mailbox Logging

Applies to: Exchange 2007, 2010, 2013, 2016, Office 365

Exchange ActiveSync (EAS) mailbox logs are protocol-level logs that show the traffic between Exchange and the EAS device.  This is assuming of course, that the device actually connects, gets past IIS, and into Exchange code.  When troubleshooting EAS issues, this is often the most useful piece of information.  Gathering these logs can be quick if you use PowerShell to do so, versus gathering them via ECP.

PowerShell Method

Enable the logging on the affected mailbox:

Set-CASMailbox alias -ActiveSyncDebugLogging:$true

Note: Get-CASMailbox will not show whether ActiveSyncDebugLogging is on or off unless you add the  -ActiveSyncDebugLogging parameter.

Reproduce whatever issue you're dealing with, then gather the logs:

Exchange 2007/2010

Get-ActiveSyncDeviceStatistics -Mailbox alias -GetMailboxLog:$true -NotificationEmailAddress yourEmailAddress@contoso.com

Exchange 2013+

Get-MobileDeviceStatistics -Mailbox alias -GetMailboxLog:$true -NotificationEmailAddresses yourEmailAddress@contoso.com

This will output the log to the screen (in 2010 and above), and email a copy of it to your email.  Easy!

Note that these cmdlets will work in all versions of Exchange from 2007-2016, however in 2013 we've deprecated Get-ActiveSyncDeviceStatistics in favor of Get-MobileDeviceStatistics, and in 2007 the cmdlets don't actually do anything (see the Exchange 2007 note below).  The cmdlet is otherwise the same.

By default, these logs will contain tags that are truncated -- the data for most tags is removed, and replaced with a tag attribute indicating how many bytes the data contains.  For example, the subject of an email may look like this:

<Subject xmlns="Email:" bytes="19"/>

...instead of this:

<Subject xmlns="Email:">This is the subject</Subject>

If the actual data is required, then enable verbose logging on each CAS the request may hit.  To do so, open the x:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Sync\web.config file (replacing V14 with V15 in 2013+), and find this tag:

<add key="EnableMailboxLoggingVerboseMode" value="false"></add>

Change that value to true.  Note that this setting is per-CAS and not per-user, so the verbosity will be dependent on which CAS the device hits.  No restart is required of IIS or the application pool.  Also note that Office 365 does not allow verbose logging, so you're stuck with using Fiddler (with the EAS Inspector for Fiddler) or working with the truncated data.

Exchange 2007

In Exchange 2007, the EAS logs are enabled per-server.  To enable EAS logging, open the x:\Program Files\Microsoft\Exchange Server\ClientAccess\Sync\web.config file, and find this tag:

<add key="MailboxLoggingEnabled" value="false"></add>

Change that value to true.  Note that this setting is also per-CAS, so the traffic will only be logged if the device hits a CAS with this enabled.  Other than this setting, the rest of the steps are the same as Exchange 2010-current.

OWA / ECP Method

This method allows end-users to easily gather their own logs through OWA -> ECP.  Simply log into ECP and go to Options -> Phone -> Mobile Phones/Devices.  This slab contains a list of the EAS devices for the mailbox, and users can enable logging and retrieve it from here. The log will be sent to the user’s mailbox.

[caption id="attachment_205" align="alignnone" width="437"] Mobile devices slab in Exchange 2013[/caption]

 

[caption id="attachment_215" align="alignnone" width="412"] Mobile devices slab in Office 365[/caption]

 

In any of the versions, select the device you want logging for, and click the "Start Logging" icon (highlighted in yellow).  After enabling the logging, reproduce the behavior and then click "Retrieve Log" which will be the same button.

Whether you use PowerShell or ECP to enable logging, the log is sent to you in an email message that has the log attached.  After 72 hours this logging is automatically disabled, so keep that in mind if you're trying to capture logs over a long period of time.  These logs are not intended to stay enabled very long.

The Exchange ActiveSync Protocol

The Exchange ActiveSync protocol is well documented, yet can be difficult to read and understand.  It’s broken up into numerous specifications, which are all listed in the Exchange Server Protocol Docs.

The main specifications you’ll likely use on a regular basis are for the contact, calendar, and commands.  All the docs for ActiveSync start with MS-AS, such as MS-ASCNTC (Contact Class), MS-ASCAL (Calendar Class), and MS-ASCMD (Command Reference).

Understanding these logs may require extensive protocol review, but some will be fairly straightforward.  SendMail for example will send an email, with tags such as <Subject> etc.

Sample Log

Here is a snippet from a sample log showing the MeetingResponse command.  For this sample, the EAS command MeetingResponse should be reviewed.  The full command reference can be found in the MS-ASCMD reference under Messages -> Message Syntax -> Commands.

 -----------------
 Log Entry: 325
-----------------

RequestTime : 
02/28/2013 17:23:23

ServerName : 
CONTOSO-E2K10

AssemblyVersion : 
14.02.0247.001

Identifier : 
114A6C98

RequestHeader : 
POST /Microsoft-Server-ActiveSync/default.eas?User=user@contoso.com&DeviceId=DMPFXZABDFHW&DeviceType=WindowsMail&Cmd=MeetingResponse HTTP/1.1
Connection: keep-alive
Content-Length: 29
Content-Type: application/vnd.ms-sync.wbxml
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Authorization: ********
Host: mail.contoso.com
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Win64; x64; Trident/6.0)
X-MS-PolicyKey: 196647767
MS-ASProtocolVersion: 14.2


RequestBody : 
<?xml version="1.0" encoding="utf-8" ?>
<MeetingResponse xmlns="MeetingResponse:">
    <Request>
        <UserResponse>1</UserResponse>
        <CollectionId>1</CollectionId>
        <RequestId>1:653</RequestId>
    </Request>
</MeetingResponse>

AccessState : 
Allowed

AccessStateReason : 
Global

ResponseHeader : 
HTTP/1.1 200 OK
MS-Server-ActiveSync: 14.2


ResponseBody : 
<?xml version="1.0" encoding="utf-8" ?>
<MeetingResponse xmlns="MeetingResponse:">
    <Result>
        <RequestId>1:653</RequestId>
        <Status>1</Status>
        <CalId>1:654</CalId>
    </Result>
</MeetingResponse>

ResponseTime : 
02/28/2013 17:23:23

Log Breakdown

Let's break down the log starting from the top.

Log Entry	This is a sequential entry number, starting at 0.
RequestTime	This is the time the request entered Exchange code, and is in the server’s time zone.
ServerName	This is the CAS that is ultimately processing the request.
AssemblyVersion	The version of the AirSync assembly that the AirSyncHandler in IIS calls into. Specifically, x:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Sync\Bin\AirFilter.dll
Identifier	A unique hexadecimal number identifying the specific request/response pair.
RequestHeader	This is the full HTTP header with redacted auth. This will show if the connection is being proxied, etc.
RequestBody	This is the decoded WBXML sent from the EAS device. Consider this the raw request from the client.
LogicalRequest	The parsed, complete XML request. This includes some optional elements that are not required, and show the default or implied settings.
AccessState	The access state for this specific device. Allowed, Blocked, etc.
AccessStateReason	The reason for the access state above. Global, Individual, etc.
ResponseHeader	The HTTP header sent by Exchange. This is pre-IIS, and IIS may add its own headers before sending the set to the client.
ResponseBody	The XML response to be sent to the device. This will be compressed into WBXML before hitting IIS.
ResponseTime	The time the response exited Exchange code and was sent to IIS.

 

I’m going to jump down to the RequestBody, since the RequestHeader is mostly just HTTP information – the HTTP verb used, the user-agent, etc. The only lines that are normally important here are the X-MS-PolicyKey and User-Agent headers. Most everything else is going to be edge-case.

The RequestBody:

 RequestBody : 
<?xml version="1.0" encoding="utf-8" ?>
<MeetingResponse xmlns="MeetingResponse:">
    <Request>
        <UserResponse>1</UserResponse>
        <CollectionId>1</CollectionId>
        <RequestId>1:653</RequestId>
    </Request>
</MeetingResponse>

Ignore <?xml>, that's the XML header.  The next tag is <MeetingResponse xmlns="MeetingResponse:">, which we'll cross-reference with the protocol.  This is where I find many people hit a wall.

Note: You can mostly ignore the xmlns.  The xmlns is the XML namespace, which at a high level specifies the specific type of MeetingResponse, and is defined in the schema , which is also in the protocol documentation.

Start at the MeetingResponse command itself. From there, we’ll drill down into the element we care about.

MeetingResponse -> MeetingResponse element -> Request element. Notice there is the Request and the Response. Now we see the “meat” of the request. The Child elements column here lists the elements with the data we care about based on the request we see in the log. UserResponse, CollectionId, and RequestId are all here.

UserResponse – 3 possible values, indicating whether the meeting is being accepted, tentatively accepted, or declined. This request has a UserResponse of 1, meaning the meeting request was Accepted.

CollectionId – String value specifying the folder that contains the meeting request. This value is obtained from a previous FolderSync (or FolderCreate) command response. If you miss those commands, you’ll have to make assumptions on what folder it’s referencing, but if you have access to the mailbox you can determine the mapping through a process detailed in a blog posting by Jim Martin.

The first FolderSync for the device will pull a folder list that is alphabetized, and the CollectionId is sequential. So for example, in a new mailbox, Calendar would be CollectionId 1, Contacts would be CollectionId 2, and so on.

If the folders change after the FolderSync, the change to the FolderHierarchy is sent to the device, but the CollectionId just increments the number. So the newest folder gets the largest number. If the device partnership is reset, then the newest folder gets a CollectionId that is in the proper alphabetical order.

RequestId – String value specifying the server ID of the meeting request message item. Notice the format here is colon-separated. FolderId:ItemId:AttachmentId. In this case the CollectionId is 1, so the RequestId is 1:653.

The ItemId here acts much like the CollectionId above. The number increments in the partnership, but on a new sync, the items will all be in sequential order. Unlike the FolderHierarchy, these items are not alphabetized, but in chronological order. The first item in the box (oldest) will be ItemId 1.

Note: ServerId, RequestId, and CalendarId (CalId in the log) are all specifying the server ID of the items.  For some commands such as Sync, FolderSync, etc you'll see ServerId instead of the latter two, and its meaning may differ depending on its context.

See [MS-ASCMD] 2.2.3.151 ServerId for more details.

The server will process the request, and send the response as shown in the ResponseBody:

 ResponseBody : 
<?xml version="1.0" encoding="utf-8" ?>
<MeetingResponse xmlns="MeetingResponse:">
    <Result>
        <RequestId>1:653</RequestId>
        <Status>1</Status>
        <CalId>1:654</CalId>
    </Result>
</MeetingResponse>

Most of the outlining structure is the same, so start with the RequestId here. Starting at the MeetingResponse command again, drill down to MeetingResponse -> MeetingResponse element -> Result element. Now we see the RequestId, Status, and CalendarId sections.

RequestId – String value specifying the server ID of the meeting request message item. The Id is 1:653, corresponding to the RequestId in the request.

Status – 4 possible values, indicating the success or failure of the MeetingResponse command. In this example the status is a 1, meaning the request was successful.

CalendarId – String value specifying the server ID of the calendar item (instead of the message object associated with the calendar item). If the meeting request is accepted, the server ID of the calendar item is returned, and is the new server ID. If you were to follow the conversation you’d see the server delete the old ID (1:653) and send down the updated 1:654 item.

Every request command and response is analyzed in a similar manner. Cross-reference the XML with the protocol docs, and use the view on the device and OWA/Outlook to visually see what’s going on. You can also mix this with message tracking logs, IIS logs, and other tools and data that we’ll delve into later.

Jason Slaughter

Comments

• Anonymous
  January 01, 2003
  @Tom - Nope, enable per CAS in 2007, and it'll be enabled for everyone who hits that CAS -- no per-user logging in 2007. That also means if an EAS device hits one CAS for one request, and another for the next -- you'll only log on the CAS that gets the request. So make sure it's enabled across the board if you're using NLB and don't have affinity configured correctly.

• Anonymous
  January 01, 2003
  There is no graceful method to do this.  The quickest way for a per-person deletion of these logs would be to use MFCMAPI (technet.microsoft.com/.../bb508857.aspx) and delete the messages from the EAS device's folder in the mailbox. Make sure the MAPI profile is not in cached mode, and look for the folder off the "Root Container" named AirSync deviceType_deviceId.  Double-click that folder and just delete all the messages in there.  Those messages each represent a Request/Response pair.

  • Anonymous
    November 29, 2017
    Hi Jason,With regards to the question about cleaning out the old logs from a mailbox. You mentioned the only way is via MFCMapi type editor. Do you know how long they are retained for before getting purged automatically?
    • Anonymous
      April 27, 2018
      @ChrisP - The logs aren't cleared out automatically. If you go over some of the built-in limits (5000 logs or 10MB) we'll delete down to half of that, starting with the oldest log.I've posted a PowerShell script that may help you in clearing out old logs.That's provided as-is of course, so check it out with -WhatIf first.

• Anonymous
  January 01, 2003
  @Joe: I went back and clarified in the blog that in Exchange 2007 it is per-server. The per-user ability is not present in Exchange 2007, so yes, you have to enable that across all CAS the user in question could connect to. Generally I use WiFi and a local connection when I'm investigating if possible.
  
  ---
  
  @PWendt: Most of the protocol log information can be found here: http://technet.microsoft.com/en-us/library/bb201675
  
  ---
  
  The below items will cover the rest:
  ---
  Sst55 -> The SyncState size is 55KB,
  SsCmt55 -> The SyncState size that has been committed to the mailbox is 55KB,
  BR1 -> The body of the message has been requested (0=False, 1=True),
  BPR0 -> The body part requested. I think this has to do with MIME parts,
  LdapC2 -> The request took 2 ldap calls,
  LdapL16 -> The ldap latency averaged 16ms

• Anonymous
  January 01, 2003
  Great. A goldmine of information for our Blackberry 10 devices. Elsa Braun, Milwaukee

• Anonymous
  January 01, 2003
  I'm not sure how she's connecting now, but it sounds like some form of desktop sync.  Desktop sync is not going to be using EAS. As for the issue at hand, look for Server IDs that start with 1.  Generally the Calendar folder will be Server ID 1 because it's the first folder alphabetically.  If you don't see <Ping>s or <Sync>s with a <CollectionId>1</CollectionId> then we're not seeing a request for that folder. I may need to add more request examples to this post, but for now you should review the Direct Push feature (technet.microsoft.com/.../aa997252(v=exchg.141).aspx).  That will go over what commands the device should be sending to actually sync down data. Lastly, you mention the meeting doesn't show up in Outlook on her desktop.  Does it appear in OWA?  If not, then you may have a different issue altogether, and at that point you'll likely need to open a support case with us.

• Anonymous
  January 01, 2003
  Great article!

• Anonymous
  January 01, 2003
  Jason - any thoughts on how to clean out or roll a Mailbox log for a given Exchange account after ActiveSyncDebugLogging has been set to true?  I was hopeful that toggling the value from true, back to false, then to true again would zero the log out.  No luck as far as I can see.

• Anonymous
  June 08, 2013
  Hi Jason, I work on an IT Helpdesk and have a user with a Samsung Galaxy S2 using Android 4.0.4. She can sync her e-mail just fine, however whenever she wants to view her Exchange Calendar she gets a "Connection Error (Exchangeaccount)". I added an appointment to her Exchange calendar and it doesn't sync to her Outlook on her Desktop. Apparently she has already taken the phone to US Cellular about this issue to get the phone factory reset and that hasn't helped. We also removed, and re-added the account, accepted the Security Settings and the email still syncs fine but not the Calendar. I turned on logging in OWA for a few days and have a 4MB EASMailboxLog_joans_SAMSUNGSCHR760_SAMSUNG3A0000030DD1F7E.txt file, what would be your suggestion to analyze this log file, I searched for MS-ASCAL and didnt find anything, I also searched for "Calendar" and am trying to figure out this XML. Any suggestions or websites you can point me in the direction in? Thanks for the article!

• Anonymous
  June 08, 2013
  Oh yea, and if she hooks up her phone to her desktop via USB then she can sync her Outlook Calendar then! Not sure what she is using to accomplish this, I had stopped by her office on Friday and discovered she could sync her Exchange Calendar fine only if she had it hooked up to her Desktop via USB, I should have asked her what APP, setting she has active to accomplish that.

• Anonymous
  December 15, 2013
  Pingback from Under The Hood: Exchange ActiveSync Mailbox Log Analysis | Office 365 Singapore for Business - Win-Pro

• Anonymous
  December 15, 2013
  Pingback from Exchange ActiveSync Mailbox Logging und Auswertung (Teil 1) | Wie die Computer mein Leben versauten!

• Anonymous
  December 15, 2013
  Pingback from Exchange ActiveSync Mailbox Logging und Auswertung (Teil 1) | Wie die Computer mein Leben versauten!

• Anonymous
  December 15, 2013
  Pingback from Exchange ActiveSync Mailbox Logging und Auswertung (Teil 1) | Wie die Computer mein Leben versauten!

• Anonymous
  December 15, 2013
  Pingback from Exchange ActiveSync Mailbox Logging und Auswertung (Teil 1) | Wie die Computer mein Leben versauten!

• Anonymous
  December 15, 2013
  Pingback from Exchange ActiveSync Mailbox Logging und Auswertung (Teil 1) | Wie die Computer mein Leben versauten!

• Anonymous
  December 15, 2013
  Pingback from Exchange ActiveSync Mailbox Logging und Auswertung (Teil 1) | Wie die Computer mein Leben versauten!

• Anonymous
  January 03, 2014
  Note: Part 2 of this series can be found here . One of best troubleshooting tools for Exchange ActiveSync

• Anonymous
  April 16, 2014
  The comment has been removed

• Anonymous
  April 23, 2014
  Jason, thanks for the info, however, for Exchange 2007 the info is not clear to me. For Ex2007 does that mean I only have to enable it on the server via web.config file and I don't have to enable per user? Or do I have to enable both per user and each cas server? Is there a separate log file created or is the data appended to the IIS log. How big do these files get? Thanks

• Anonymous
  June 06, 2014
  Jason - Great article! One question I have is for 2007, we enable across each cas, but then can we toggle per user on and off?
  
  Thanks

• Anonymous
  February 06, 2015
  Is that we can run this command only in CAS server?

• Anonymous
  February 27, 2015
  Just FYI, being unable to clear out old logs makes me reluctant to take advantage of this.

• Anonymous
  March 10, 2015
  The comment has been removed

• Anonymous
  March 10, 2015
  Nevermind, I think I see how to do it. I'll have to use the powershell command to change the email address under notification email... I was focused on the ecp. Thanks.

• Anonymous
  May 04, 2015
  Recently we worked on an Interesting issue where in we noticed that some of the Folders/Subfolders were

• Anonymous
  May 04, 2015
  Recently we worked on an Interesting issue where in we noticed that some of the Folders/Subfolders were

• Anonymous
  June 29, 2015
  Hi, can you detail the four possible status values? I see that 1 = successful but what about the other 3? Thanks!

• Anonymous
  July 13, 2015
  @Matthew - For common status codes (codes that apply to all command types), you can reference this:
  
  2.2.4 Common Status Codes
  https://msdn.microsoft.com/en-us/library/ee218647.aspx
  
  For specific codes, do a search for ms-ascmd status command, where command is sync, ping, etc. For example, the sync-specific status codes are here:
  
  2.2.3.162.16 Status (Sync)
  https://msdn.microsoft.com/en-us/library/gg675457.aspx

• Anonymous
  November 24, 2015
  Many thanks for this, Jason, one of the best Exchange posts I've ever seen.
  
  One irritation we are experiencing is that the logging is periodically switching itself back to False again. Does it do this after a log gets to a certain size? Is there any way of configuring this so it doesn't happen so often?

• Anonymous
  February 08, 2016
  @ grahame - EAS logging will disable itself after 72 hours in 2010 and higher. Unfortunately there is no way to modify this, so you'll need to re-enable before then to get a continuous log.
  
  Note that while this logging is enabled, that user will generate more transaction logs than usual, since the logs are stored in the mailbox.

• Anonymous
  February 22, 2016
  Nice work on this post. One thing I can't figure out is what config file on Exchange 2013 do you edit to get properly filled Subject fields? The Sync web.config doesn't appear to handle that anymore. - thx

  • Anonymous
    April 22, 2016
    The web.config should still control verbose logging in 2013 and 2016. The file is C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Sync\web.config: I checked in code and it's definitely still in-use, so I'm not sure what's going on there. Are you sure it's enabled on the CAS you're hitting (NLB)? You shouldn't even need to restart the app pool since web.config changes are generally read immediately after a change notification.

• Anonymous
  February 24, 2016
  I refer others to this page at least once a week. I work supporting an EAS client. Thanks for this page!

• Anonymous
  March 24, 2016
  The comment has been removed

  • Anonymous
    March 28, 2016
    That's quite odd. The cmdlet itself was actually created in 2005, so it's certainly there in 2010. Are you sure you're running it from and Exchange Management Shell window and not just a Windows PowerShell window?

• Anonymous
  October 14, 2016
  Jason, if I enabled "ActiveSync logging for one user through OWA in their account, how can I monitor this log file..?

  • Anonymous
    October 14, 2016
    Well you can pull the log via the Get-ActiveSyncDeviceStatistics cmdlet at the top of this post, but there aren't any automatic notifications or anything like that. Note that the logs are designed to be troubleshooting tools, not monitoring.If you're wanting to monitor for a specific error etc, you could write a PowerShell script to pull the log on an interval and parse that out.

• Anonymous
  November 20, 2016
  Hello, I need to collect EAS logs and I'm a little bit confused. Here it goes: Considering that I have Exchange 2010, what's the difference between running command "Export-ActiveSynclog cmdlet" (it parses the required IIS log file in CAS and export several files for ActiveSync analysis) and the this command "Set-CASMailbox alias -ActiveSyncDebugLogging:$true" (seems to enabale logging for EAS in a specific Mailbox) followed by "Get-ActiveSyncDeviceStatistics" (to get those generated logs in the mailbox)? Both approaches seem similar to me, one just reads data in IIS logs and another in the user's mailbox (isn't everything already present in the IIS log?). Can you clarify this question to me, please? Are these approaches additional or excludents?

  • Anonymous
    December 05, 2016
    IIS logs aren't nearly as detailed as an EAS mailbox log, and the Export-ActiveSyncLog cmdlet is not designed to troubleshoot an individual's EAS issues. That cmdlet is more for aggregate data to analyze overall EAS usage.

• Anonymous
  February 13, 2017
  Just grasping at straws but ever heard of issues with activesync and ios causing some calendar items to not update? I am unable to determine a pattern for why this happens but some appointments are not updating correctly when changes are made from exchange.I see when the updates are made that the iOS device spins indicating that it is processing a notification but it never changes the appointment on the calendar.This is with Exchange 2010 sp3 UR15I did a log trace on the iPhone and the logs indicate the following:Feb 6 16:48:21 iPhone dataaccessd(CalendarDatabase)[181] : 25534103: Updating last saved to 508050000Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : CALNBulletinBoardProvider notified about darwin notification Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Received notification: []Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Sync started. Suppressing updates while it runs.Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Received notification: []Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Sync started. Suppressing updates while it runs.Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Sync started. Suppressing updates while it runs.Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Received notification: [CalSyncClientBeginningMultiSave].Feb 6 16:48:21 iPhone calaccessd(EventKit)[8639] : Sync started. Suppressing notification monitor checks while it runs.Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Installing sync yield timer for travel engine: [].Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Installed sync yield timer with [240] second length for travel engine: [].Feb 6 16:48:21 iPhone MobileCal(Accounts)[8856] : "The connection to ACDAccountStore was invalidated."Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Sync running. Waiting for it to finish before updating in .Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Sync running. Waiting for it to finish before updating in .Feb 6 16:48:21 iPhone duetexpertd(ProactiveExperts)[162] : PEXConnectionsExpert: reloading events due to EKEventStoreChangedNotificationFeb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : CALNBulletinBoardProvider notified about darwin notification Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Received notification: []Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Sync running. Waiting for it to finish before updating in .Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Received notification: []Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Sync running. Waiting for it to finish before updating in .Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : database changedFeb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Fetching notifications from the monitor.Feb 6 16:48:21 iPhone mediaserverd(VoiceTrigger)[30] : ::: heartbeat: 44740608 score: 1.691265Feb 6 16:48:21 iPhone kbd(ProactiveExperts)[146] : PEXConnectionsExpert: reloading events due to EKEventStoreChangedNotificationFeb 6 16:48:21 iPhone calaccessd(EventKit)[8639] : Sync running. Waiting for it to finish before checking for updates.Feb 6 16:48:21 iPhone kbd(ProactiveExperts)[146] : PEXConnectionsExpert: reloading events due to EKEventStoreChangedNotificationFeb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Database changed.Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Sync running. Waiting for it to finish before updating.Feb 6 16:48:21 iPhone calaccessd(CalendarNotification)[8639] : Received notification: [_CalDatabaseChangedNotification].Feb 6 16:48:21 iPhone MobileCal(EventKit)[8856] : Event [] is marked as needing a location prediction. Will begin predicting.Feb 6 16:48:21 iPhone locationd[7573] : {"msg":"client getting effective client name", "clientName":"com.apple.mobilecal", "bundleId":"com.apple.mobilecal", "bundlePath":""}Feb 6 16:48:21 iPhone locationd[7573] : already authorized WhenInUse executable com.apple.mobilecalFeb 6 16:48:21 iPhone locationd[7573] : Authorization status for is Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : client, , called, Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : , , location, , calendarIdentifier, Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : sending 0 predicted locations of interest to client, Feb 6 16:48:21 iPhone MobileCal(CalendarFoundation)[8856] : Error fetching locations of interest for title Broken Appointment, location: , calendar: 621C317A-0303-4A73-922F-070DA4940C4B: Request timed outFeb 6 16:48:21 iPhone MobileCal(EventKit)[8856] : Event [] is marked as needing a location prediction. Will begin predicting.Feb 6 16:48:21 iPhone locationd[7573] : {"msg":"client getting effective client name", "clientName":"com.apple.mobilecal", "bundleId":"com.apple.mobilecal", "bundlePath":""}Feb 6 16:48:21 iPhone locationd[7573] : already authorized WhenInUse executable com.apple.mobilecalFeb 6 16:48:21 iPhone locationd[7573] : Authorization status for is Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : client, , called, Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : , , location, , calendarIdentifier, Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : sending 0 predicted locations of interest to client, Feb 6 16:48:21 iPhone MobileCal(CalendarFoundation)[8856] : Error fetching locations of interest for title Broken Appointment, location: , calendar: 621C317A-0303-4A73-922F-070DA4940C4B: Request timed outFeb 6 16:48:21 iPhone MobileCal(EventKit)[8856] : Event [] is marked as needing a location prediction. Will begin predicting.Feb 6 16:48:21 iPhone locationd[7573] : {"msg":"client getting effective client name", "clientName":"com.apple.mobilecal", "bundleId":"com.apple.mobilecal", "bundlePath":""}Feb 6 16:48:21 iPhone locationd[7573] : already authorized WhenInUse executable com.apple.mobilecalFeb 6 16:48:21 iPhone locationd[7573] : Authorization status for is Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : client, , called, Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : , , location, , calendarIdentifier, Feb 6 16:48:21 iPhone routined(libcoreroutine.dylib)[33] : sending 0 predicted locations of interest to client, Feb 6 16:48:21 iPhone MobileCal(CalendarFoundation)[8856] : Error fetching locations of interest for title Broken Appointment, location: , calendar: 621C317A-0303-4A73-922F-070DA4940C4B: Request timed out

  • Anonymous
    February 13, 2017
    Hey Nick, just looking at this by itself unfortunately isn't enough. As I don't work for Apple I'm not super familiar with their logging, so I don't know what it means when their logging says it erred fetching locations of interest (among other things). I suggest opening a support case with us so we can properly investigate. Even then, you may end up with a case open with both Apple and Microsoft and all of us working together.