none
[MS-OXOCAL] PR_OWNER_APPT_ID values ? RRS feed

  • Question

  • I'm following the instructions in the MS-OXOCAL document to create a
    meeting request.  One of the fields to populate is
    PidTagOwnerAppointmentId / PR_OWNER_APPT_ID.  The document defines
    this value as "the number of minutes between the start time and
    midnight, January 1, 1601".  For messages created now, in March 2010,
    that would give values in the order of 215203440.  However, using
    OutlookSpy, I can see that messages created manually within Outlook
    have values more like 1900099546, around 9 times higher.

    The example in MS-OXOCAL is from 26 Feb 2008 and has the value
    1301555160.  Now if you follow the document's own definition, that
    would put the message somewhere around the year 4000.  Or, if it
    matches Outlook, it gives a difference of 598544386 in two years,
    which works out to about 10 a second, which means that it starting
    counting 6.34 years ago.

    Can anyone explain what is going on  ?     Or is my maths just
    screwy ?

    - Tim Dale, BRE

    Wednesday, March 3, 2010 4:08 PM

Answers

  • Tim,

     

    The property in question is not necessary to implement the protocol, hence we have not documented the underlying algorithm. The value is a semi-unique value and various implementers will have their own algorithm against the property in question.

     

    Dominic Michael Salemno

    Senior Support Escalation Engineer

    US-CSS DSC Protocols Team 

     

    Friday, April 23, 2010 8:01 PM

All replies

  • Hello Tim,
     
    Thank you for your question regarding [MS-OXOCAL]! Someone from the Protocol Documentation team will be contacting you soon to begin working with you on this question.

    Thanks
    John Dunning
    Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM
    Wednesday, March 3, 2010 4:39 PM
  • Tim,

    I am the engineer who has taken ownership of your issue. I am currently investigating this and will update you as things progress.

    Dominic Michael Salemno
    Senior Support Escalation Engineer
    US-CSS DSC Protocols Team

    Friday, March 5, 2010 7:03 PM
  • Tim,

    I am still investigating this property for you.

    Dominic Michael Salemno
    Senior Support Escalation Engineer
    US-CSS DSC Protocols Team
    Monday, March 15, 2010 5:55 PM
  • Tim,

    I have no new information for you currently.

    Dominic Michael Salemno
    Senior Support Escalation Engineer
    US-CSS DSC Protocols Team
    Tuesday, March 23, 2010 7:09 PM
  • Tim,

    The Id in question is based on a mathematical operation utilizing the number of minutes from January 1, 1601 and is subsequently cast to a ULONG. 

    Does this answer your question?

    Dominic Michael Salemno
    Senior Support Escalation Engineer
    US-CSS DSC Protocols Team

    Wednesday, March 31, 2010 5:27 PM
  • Dominic, thanks for responding.

    Sorry for the delay in me responding, but I've been working away from the office.

    Anyway, what you describe is what I'm doing,

    but that doesn't appear to be what Outlook is doing when appointments are created manually.

    See my first post for the values I am seeing.  As I explained, by your definition, the appointments in our Outlook system are somewhere around the year 4000.

    Can you explain it ?

    And does it matter if the values I'm putting it don't line up with other appointments on the system ?

    Regards,

    Tim Dale, BRE

    Thursday, April 8, 2010 7:45 AM
  • Tim,

    I am currently investigating this for you. I will update you when I have new information.

    Dominic Michael Salemno
    Senior Support Escalation Engineer
    US-CSS DSC Protocols Team

    Monday, April 12, 2010 2:35 PM
  • Tim,

    I am still investigating and will follow-up with you shortly.

    Dominic Michael Salemno
    Senior Support Escalation Engineer
    US-CSS DSC Protocols Team

    Wednesday, April 21, 2010 5:08 PM
  • Tim,

     

    The property in question is not necessary to implement the protocol, hence we have not documented the underlying algorithm. The value is a semi-unique value and various implementers will have their own algorithm against the property in question.

     

    Dominic Michael Salemno

    Senior Support Escalation Engineer

    US-CSS DSC Protocols Team 

     

    Friday, April 23, 2010 8:01 PM