none
StartTime missing in ActiveSync Calendar Event Change RRS feed

  • Question

  • In MS-ASCAL, it says "A Sync command response MUST contain one instance of the StartTime element."

    However, my activesync client shows that it gets something like this:

              <Change>
                <ServerId>------------------------------</ServerId>
                <ApplicationData>
                  <calendar:DtStamp>20171021T152339Z</calendar:DtStamp>
                </ApplicationData>
              </Change>

    Ghosted properties are only used in Sync requests as far as I understand. Any idea why my client gets something like this? Thanks.

    Monday, November 27, 2017 6:49 AM

Answers

  • To update the community on this issue, after testing and review of change filtering code, we determined that for Exchange ActiveSync protocol versions >= 12.0, if the DtStamp and/or Attendees have changed, a Sync Change response will contain only the affected elements (i.e. DtStamp or Attendees) and will not include the StartTime element as [MS-ASCAL] 2.2.2.42 states. We will be updating the document to state the correct behavior. Protocol versions <12.0 are not affected.

    Thanks,

    Tom

    Monday, December 4, 2017 11:37 PM
    Moderator

All replies

  • Hi Carson,

    Thank you for your Protocols question. One of our engineers will respond soon.

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Monday, November 27, 2017 6:17 PM
    Moderator
  • Hi Carson,

    I will look into this for you. What version of the protocol, client and server are you using? 

    Best regards,
    Tom Jebo 
    Sr Escalation Engineer
    Microsoft Open Specifications Support


    Monday, November 27, 2017 7:15 PM
    Moderator
  • Looking at the current specification, 3.2.5.3.3 "Omitting Ghosted Properties from a Sync Change Request" says that you need to use the Supported element in the Sync command request in order for subsequent Change elements to include properties that would otherwise be ghosted. Can you show me the command that was issued originally?

    Tom

    Monday, November 27, 2017 10:26 PM
    Moderator
  • Better yet, if you can send me a Fiddler trace of the conversation, that would help. 

    Please send to dochelp@microsoft.com, referencing my name and the URL for this thread.

    Tom

    Monday, November 27, 2017 11:01 PM
    Moderator
  • It is a sync change response. I issued a sync request (the client is kind of read-only) with no special params I think. The server is outlook.office365.com. I'm just trying out some open-source client out there. Protocol version should be 14.1 but I'm not sure if I mentioned that in the request. If not, it may be 16.0.

    Off-topic: Is it possible for you to notify your colleagues at outlook.com that their EAS AutoDiscover service has been down for weeks? The Customer Service of outlook.com has no clue of what's happening.
    Tuesday, November 28, 2017 4:26 AM
  • The reason I asked for trace data is that I'm doing the same kind of sync going to outlook.office365.com as well and still get the StartTime element included in the Change response. 

    Tom

    Tuesday, November 28, 2017 6:39 PM
    Moderator
  • I would still like to see a trace of this if you can provide it. Please include the the request that made the change as well as the sync request and response.

    In the meantime, I am still digging to see what conditions might apply to this situation.

    Tom

    Tuesday, November 28, 2017 11:51 PM
    Moderator
  • I have sent you an email at dochelp@microsoft.com. Thanks.
    Wednesday, November 29, 2017 9:27 AM
  • Thanks Carson, got the email.
    Wednesday, November 29, 2017 6:34 PM
    Moderator
  • To update the community on this issue, after testing and review of change filtering code, we determined that for Exchange ActiveSync protocol versions >= 12.0, if the DtStamp and/or Attendees have changed, a Sync Change response will contain only the affected elements (i.e. DtStamp or Attendees) and will not include the StartTime element as [MS-ASCAL] 2.2.2.42 states. We will be updating the document to state the correct behavior. Protocol versions <12.0 are not affected.

    Thanks,

    Tom

    Monday, December 4, 2017 11:37 PM
    Moderator