none
Exchange generates failure report emails for Inbox items which haven't attempted to be synced RRS feed

  • Question

  • Hello,

    Our ActiveSync client is reporting errors to the user when the user is sent certain types of recurrence invites. If an invite to a meeting is sent from the Outlook Web App to the user, and the user then syncs their Inbox (using our ActiveSync client and the Sync command), instead of receiving the correct email, they will get an email indicating an error: From: Microsoft Exchange on Behalf of *user’s name* Subject: Synchronization with your WinRT failed for 1 items. Body: Synchronization with your Winrt failed for 1 items. The following items couldn’t be sent to your mobile phone. They haven’t been deleted … Item Folder: Inbox Item Type: IPM.Schedule.Meeting.Request Item Created: *date* Item Subject: *subject of missing email* (WinRT is the name of our client currently.) This occurs consistently when the invite is for a recurring meeting, which occurs on the last day of a month, yearly. (Yearly on the nth day of the month) It also seems that after one of these error emails appears, other items start to be added in with it, although this could just be the result on my side from a lot of testing side effects. There’s two strange things to note about this error. The Exchange server never attempts to even send the items via ActiveSync to our client, so the error does not seem to be caused by our Sync request. I’ve used Fiddler to examine the calls, and we never receive the original message in any form. The Windows Mail client (in Windows 8.1), which uses ActiveSync, has no problem Syncing the very same items that are causing the errors to appear. This gives the impression that something can be done to remedy the problem, but I have no idea what.

    Thanks


    ArchieCoder

    Tuesday, December 9, 2014 6:30 PM

Answers

  • Hello,

    Good news, it seems that this is a non-issue now. Our IT team was very slow to install the Update Rollup 3 as described here: http://support.microsoft.com/kb/2457304

    It was finally installed yesterday. After doing some testing, it appears that this has fixed the issue. I haven’t been able to reproduce the problem after the install.

    I’m sorry that we took so much of your time when there was an easy fix! Thanks for your patience.

    Thanks


    ArchieCoder

    • Marked as answer by ArchieCoderMVP Thursday, January 15, 2015 3:53 PM
    Thursday, January 15, 2015 3:52 PM

All replies

  • Hello ArchieCoder

    Thanks for contacting Microsoft Support, a support engineer will be in touch to assist further.

    Regards.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Tuesday, December 9, 2014 10:22 PM
  • Hello ArchieCoder,

    I will be working with you on this issue. Some initial research turned up a thread on the Exchange Development forum that might be relevant to what you are seeing: https://social.msdn.microsoft.com/Forums/en-US/729da1bc-851c-4d47-b76d-ae2575a91b7e/synchronization-with-your-winrt-failed-for-1-items-error-from-exchange-server?forum=exchangesvrdevelopment.

    If you could collect a packet capture (Wireshark/Netmon/Message Analyzer) during your client's sync conversation and then another from the Windows Mail sync conversation, we can take a look at this from the protocol perspective and perhaps offer some additional insight, if installing an Exchange update as per the other thread does not resolve the issue.

    Please be sure that any traces you collect contain no confidential information and send them to my attention at dochelp at microsoft dot com.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Wednesday, December 10, 2014 4:02 PM
  • Hello Matt,

    Thanks for your assistance, I sent you an email.


    ArchieCoder

    Thursday, December 11, 2014 7:51 PM
  • Hello ArchieCoder,
     
    When comparing the ActiveSync traces from your client and from Windows Mail, I noticed that the two are syncing different sets of collections. I also noticed that the failure message is associated with CollectionId 12:
     
    <?xml version="1.0" encoding="utf-8"?>
    <airsync:Sync xmlns:airsync="AirSync">
       <airsync:Collections>
          <airsync:Collection>
             <airsync:SyncKey>565388745</airsync:SyncKey>
             <airsync:CollectionId>12</airsync:CollectionId>
             ...
                         <airsyncbase:Data>From: ...
    Subject: Synchronization with your WinRT failed for 1 items.Thread-Topic:
     
    The Windows Mail client is not syncing the collection with CollectionId 12. Here is the list of collections it is syncing:
     
    1
    2
    3
    5
    7
    10
    13
    17
    18
    24
    25
     
    Putting aside the question of whether the error is valid or not for a moment, is it possible to modify your client to not sync the collection with CollectionId 12? If you can do that, that would be a useful test to know if the error still occurs or not. If it does not occur, we can look further into what collection this is (I either don't have that data in the traces you sent, or I'm overlooking it), and determine whether the behavior is expected or not.
     
    Best regards,
    Matt Weber | Microsoft Open Specifications Team
    Monday, December 22, 2014 11:00 PM
  • Hello Matt,

    It appears that the collection with CollectionId 12 is actually the Inbox folder. It also appears that the Inbox folder on the Windows Mail client is identified as 5. Is it possible that the same collection would be identified with different numbers using two different clients? The initial sync for the Windows Mail client was performed a long time (many months) before the initial sync for our client (which is refreshed frequently in the process of development).

    Thank you


    ArchieCoder

    Tuesday, January 6, 2015 4:43 PM
  • Hello ArchieCoder,

    > Is it possible that the same collection would be identified with different numbers using two different clients?

    The CollectionId value corresponds to the ServerId that was returned in a FolderSync response, and that is defined as a "server-unique identifier for a folder on the server." ([MS-ASCMD] §2.2.3.151.3). As long as the clients are talking to the same server, I would expect them to get the same value for the same folder.

    Currently, the special Inbox folder is always identified by CollectionId 5. This does not appear to be documented and as such should not be relied upon to always and forever be true, but you can see in the informative sections of several specifications ([MS-ASEMAIL] §4.1.1, for example) that this is assumed to be the case.

    Note that there's nothing that would prevent the creation of another folder named "Inbox", but it would be distinct from the special Inbox folder. That seems like the most likely scenario here, but without seeing the FolderSync responses that is just a guess.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Tuesday, January 6, 2015 7:49 PM
  • Hello Matt

    I looked a little deeper and it still seems the Inbox folder on our client is being given the Id of 12. This folder has a Type of 2 (Default Inbox folder). Here’s the pertinent section of the FolderSync response, and I’ve also attached the Fiddler capture of the FolderSync command if you’d like to examine it.

    <Add>
          <ServerId>12</ServerId>
          <ParentId>0</ParentId>
          <DisplayName>Inbox</DisplayName>
          <Type>2</Type>
    </Add>

    I’m not sure we got into this state where the Inbox folder has an unusual Id. Is there any chance this is related to the syncing issue?

    PS: I sent you the Fliddler file by email.

    Thanks


    ArchieCoder


    Wednesday, January 7, 2015 5:56 PM
  • Hello ArchieCoder,

    This is certainly not what I would expect to see. However, I can't say with certainty that it's related to the syncing issue.

    I went back and looked at the Fiddler trace you took from the Windows Mail client. It gets the same FolderSync response. The first three folders in the response look like I expect--Calendar has ServerId 1, Contacts has ServerId 2, and Deleted Items has ServerId 3. After that, the ServerId value jumps to 11 for the Drafts folder, so it and all of the subsequent folders have a ServerId value that is 7 higher than what I would expect to see.

    What seems especially weird to me is that the Windows Mail client proceeds to issue a Sync request for the list of CollectionIds I reported earlier, despite several of them being absent from the FolderSync response. Furthermore, it looks like the Windows Mail client is getting Inbox items that are identified as being in CollectionId 5:

    <?xml version="1.0" encoding="utf-8"?>
    <airsync:Sync xmlns:airsync="AirSync">
       <airsync:Collections>
          <airsync:Collection>
             <airsync:SyncKey>933450273</airsync:SyncKey>
             <airsync:CollectionId>5</airsync:CollectionId>
             <airsync:Status>1</airsync:Status>
             <airsync:Commands>
                <airsync:Add>
                   <airsync:ServerId>5:391</airsync:ServerId>
                   <airsync:ApplicationData>
                      <email:Subject>Canceled: Last day of december</email:Subject>

    I'm really at a loss for what is going on with this. How difficult would it be for you to test this with your client assuming that Inbox is CollectionId 5 instead of the 12 that is returned from the FolderSync? I am afraid we might be focusing too closely on this particular aspect of the issue without being sure it could be causing the real problem, so I think it would be good if you can either reproduce the failure syncing CollectionId 5 instead of 12, or show that your client fails in some other way if it tries to sync CollectionId 5. A Fiddler trace of the outcome of that test including both the FolderSync response and Sync request/response would be the next logical step here, I think, assuming that that is doable. Please let me know what you think.

    Best regards,
    Matt Weber | Microsoft Open Specifications Team

    Wednesday, January 7, 2015 8:38 PM
  • Hello,

    Good news, it seems that this is a non-issue now. Our IT team was very slow to install the Update Rollup 3 as described here: http://support.microsoft.com/kb/2457304

    It was finally installed yesterday. After doing some testing, it appears that this has fixed the issue. I haven’t been able to reproduce the problem after the install.

    I’m sorry that we took so much of your time when there was an easy fix! Thanks for your patience.

    Thanks


    ArchieCoder

    • Marked as answer by ArchieCoderMVP Thursday, January 15, 2015 3:53 PM
    Thursday, January 15, 2015 3:52 PM