none
What version of spec MS-PST outlook 2007/2010 REALLY conforms to??? RRS feed

  • Question

  • Hi, all!

    I'm using MS-PST of rev.1.06 v20110608 edition.

    Some facts:

    1. DList. In .pst created with Outlook 2007 there is not any DList. In spec said that DList should be used instead of other deprecated structures.

    2. FMap and FPMap. Spec says that 'Implementation SHOULD NOT use' them. DList should be used instead. But in fact - FMap and FPMap are used. 

    3. Template Tables (2.4.4.4.1, 2.4.4.5.1 and other) from real .pst (made with Outlook 2007) contain column set that differs from declared in spec.

    I'm just started investigation. Most likely there are many other differences.

    So What Exactly spec of .pst-file should I use???  ... to write really working implementation of .pst-writer. The .pst-reader is done. It works. I need to create working .pst-writer.

    Sunday, December 4, 2011 1:16 PM

Answers

  • The property ID in this context (IE - on a message) absolutely identifies the property being requested, and the type identifies the type it is being requested as. The expectation is that either type is served from the same underlying data. We would not expect, for example, for the streams retrieved using PidTagBodyHtml and PidTagHtml to represent two different data sources. In fact, if they did represent two different data sources, that would be a bug in the provider. A change to one should always be reflected in the other (on re-read of course).

    Incidently, the relationship between the various body properties is documented extensively in the Best Body Protocol documentation and MS-OXCMSG. Could you point at a specific section you believe is not clear?

    Saturday, June 16, 2012 8:23 PM

All replies

  • Hi committed,

    Thanks for posting on the MSDN Forum. One of our support engineers will respond soon.

    Regards,
    Vilmos Foltenyi - MSFT

    Sunday, December 4, 2011 7:15 PM
  • Hi Committed, I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team
    Monday, December 5, 2011 6:48 PM
    Moderator
  • Hi, JCurry!

    All said below is related to empty .pst created with Outlook 2007 (w/o SP2). If it's needed I can send it to you.

    I need to understand how to build .pst. Now I'm waiting the response/information from you. At the same time I'm trying to understand the nature Working empty .pst file. Here are some more questions:

    1. In NBT there are entries with all fields zeroed: bidData = 0x0, bidSub = 0x0, bidParent = 0x0. What the meaning/purpose such kind of NBTEntry ??? Are they mandatory or optional?

    2. Named Property Lookup Map is quite far from empty. Topic 2.7 - Minimum PST Requirements - says nothing about it. At the same time it contains 40 entries. I can list them here if needed. Yes, I can copy them in my own .pst. But it doesn't give me understanding what they are for. Who, when and how uses these entries??? Which of them are mandatory, which are not?

    3. There is very unclear situation with folders. Empty .pst does not contain Inbox and Outbox folders. Nevertheless in NBT there are entries with specific for these folders predefined NID (0x0B and 0x0C). But!... There is only one entry for each of mentioned folders. But SHOULD be four for each: PC, HT, CT, ACT (look at 2.4.4.7 Anatomy of a Folder Hierarchy). So! What's about it?

    4. The similar situation with 'search'-folders.... They present in NBT but partly. One or two pieces instead of four. How to deal with it? Maybe there are some special rules for special folders?

    It's only part of my questions. But if you make it clear - it'll really help me A LOT! And I DO believe not only me.

     

    Thank You for Your Work.

     

    P.S.: I've found online-msdn page where listed what versions of Outlook (2003/2007/2010 with or without SP) what internal features use or not. It makes picture slightly more clear. But it does not change anything and does not solve my problem.

    Monday, December 5, 2011 8:56 PM
  • Hi Committed, it's important to understand that the MS-PST (and other) documents always refer to the latest version of a specification. In the case of MS-PST, it covers .PST files created and modified by Outlook 2010. You may find differences if you are looking at a .PST file that was created by a previous version, such as differences in the Hierarchy Table Template.

     

    Throughout the document you will also see links to behavior notes that look like this <x>. Behavior notes describe behavior differences between the various supported versions of a product. The answers to your first 2 questions are covered by several behavior notes in Appendix B.

     

    <2> Section 1.3.2.3: Office Outlook 2003 and Office Outlook 2007 without Service Pack 2 do not use or create Density Lists.

     

    <14> Section 2.2.2.7.3: Office Outlook 2003 and Office Outlook 2007 without Service Pack 2 do not use the Density List, and always use the PMap to locate free Pages.

     

    <15> Section 2.2.2.7.4: Office Outlook 2003 and Office Outlook 2007 without Service Pack 2 do not create or use the Density List, and always use the PMap, FMap, and FPMap to locate free Pages.

     

    <16> Section 2.2.2.7.5: Office Outlook 2003 and Office Outlook 2007 without Service Pack 2 do not create or use the Density List, and always use the FMap to locate free Pages.

     

    <17> Section 2.2.2.7.6: Office Outlook 2003 and Office Outlook 2007 without Service Pack 2 do not create or use the Density List, and always use the FPMap to locate free Pages.

     

    <20> Section 2.6.1: Office Outlook 2003 and Office Outlook 2007 without Service Pack 2 update and maintain FMaps.

     

    <21> Section 2.6.1: Office Outlook 2003 and Office Outlook 2007 without Service Pack 2 update and maintain FPMaps.

     

    Please let me know if this helps.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team
    Tuesday, December 6, 2011 3:38 PM
    Moderator
  • Hi, JCurry.

    Please, look at my last post 'post scriptum'. There I'm telling exactly about you quoted. So I found it several days ago. And it's easy coz it already written, it exists, it is known fact. But all the rest what I asked .... - where to find answers on these questions?

    So by now I have not received any help.... :(((

     

    What's about NBT entries with all zero fields?

    What's about Folders with strange structure?

    What can you say about Named Property Lookup Map??

    Tuesday, December 6, 2011 4:15 PM
  • Hi Committed, I will try to address each of your additional questions…

     

    Question 1:

    It's very likely that the NBT Page isn't full. Make sure you look at the cEnt value to see how many records it contains before parsing the rgentries array. See section 2.2.2.7.7.1 for more information.

     

    Question 2:

    The MS-PST specification does not cover everything that Outlook does when it creates a new .PST file. Outlook specific functionality is not considered part of the file format documentation. Please take a look at section 2.4.2.2 for additional information about how the Named Property Lookup Map is used. Named properties are similar to standard properties with the difference being that they will have an ID in the range of 0x8000 to 0x8FFF. When you encounter a property like this you will need to look it up in the NPLM. The wPropIdx property of the NAMEID record maps directly to the NPID value - 0x8000. I believe this also addresses one of the questions that you asked in the other thread.

     

    Questions 3 & 4:

    This goes back to what I mentioned in my previous post. There are going to be differences between a new .PST file generated by Outlook 2010 and Outlook 2007. You should generate a new .PST file with Outlook 2010 if you expect it to match the spec. Otherwise, you should continue to expect to find differences.

     

    I hope this helps you.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team
    Tuesday, December 6, 2011 6:44 PM
    Moderator
  • eeeeeehhhhh.......

    I'm Sorry, JCurry.... It was a Joke? R U kidding me???

    Do you really believe that ppls come here to receive your 'it's very likely' instead of 'in fact it is....' ????

    Apparently you even have not troubled yourself to create empty .pst file and look inside before to start writing in here your ridiculous 'very likely' and other guesses.

     

    Q1.

    Your attempt to guess is not true because:

    -- records with data = 0, sub = 0 and parent = 0 have correct predefined NID value.
    -- these records located inside of array but not out of it. That is there are 'normal' entries before these zeroEntries and after.

    NBT of 2007 and 2010 looks very similar except of couple entries. And in both of them there are the zeroEntries..... purpose of which I vainly hoped to get to know here.

     

    Q2.

    I didn't ask about 'what Outlook DOES to create .pst file'. So I don't know why you're writing it.

    Further you make copy'n'paste of documentation that I know already by heart. WHAT FOR? Why???

    At the same time you haven't added any new information or technical details concerning the matter.

    In spec - MS-PST.pdf - all you here said - already exists!!! Is it your help? :))

     

    Q3.

    You're writing about things you don't know exactly. I thought that MS's pro is able to give complete and accurate explanations.

    I created .pst 2007 and 2010, parsed them and compared. They looks very similar but there are some slight differences. But it does not matter. At all! The differences between them and what is said in spec - that really matters. And pst'2010 differs from spec dramatically. It's very strange that you don't know it.

     

    Generally I've got your message :) Decompilation is my friend. Yep? :))

    Sorry if any. I really didn't mean to be rude.

     

    Wednesday, December 7, 2011 6:36 PM
  • Hi Committed, I'm sorry if I was not able to provide you with the details that you are looking for. We do not assume a certain level of knowledge when responding to questions. We can only interpret the questions to the best of our ability and provide you with what we believe is the answer that you are looking for. If we misunderstand your question, or do not provide you with the answer that you are looking for, then we appreciate you letting us know that and providing additional details so that we can better understand your request.

     

    Yes, I do have an empty .PST file that I look at for questions like this. It was created with Outlook 2010. I do not have an empty .PST file that was created by Outlook 2007.

     

    I will try to address your first question again…

     

    After looking at your question again I recalled an issue with the documentation that has yet to be fixed. When you look at the table in section 2.2.2.7.7.1 that describes the types of records in the rgentries array you'll notice that it shows that a NBTENTRY is 32 bytes for Unicode files. But, if you look at the actual NBTENTRY structure in section 2.2.2.7.7.4 it only takes up 28 bytes. Those 2 things obviously conflict with each other. What's missing is the fact that the NBTENTRY is padded out to 32 bytes with an extra 4 bytes of 'junk' at the end. If you parse the rgentries array in 28 byte chunks you will get some odd results. You need to parse it in 32 byte chunks and ignore the last 4 bytes. The description for cbEnt hints at this with the statement "Implementations MUST use the size specified in cbEnt to advance to the next entry." but it's easy to overlook. There will be information added to the document that makes this clearer in the future. Take a look at your code to see if this is the case.

     

    Looking at your other post, I see that the scanpst.exe file is failing when it gets to the Node Btree. When you create your PST from scratch are you running into this same problem? Are you writing your NBTENTRY records as 28 bytes or 32?

     

    Note: I believe that the BBTENTRY has this same issue. The structure contains  20 bytes of actual data and 4 bytes of junk to pad it out to 24 bytes.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team
    Thursday, December 8, 2011 7:10 PM
    Moderator
  • Hi, JCurry!

    I appreciate your patience.

    Well, let's go on....

    1. I know this trap you talking about. I faced it about 2+ months ago.

    2. Apparently I gave not enough of introductory facts and here they are:

    -- all I do in terms of reading/parsing of PST (as way to proof my understanding PST-nature) gives the same results that we get with:
    http://pstviewtool.codeplex.com/documentation
    I'm sure that you know this project (http://pstsdk.codeplex.com/) and this tool.

    -- the reader-part of my code can do the same that this tool is able and much more. There are not any differences in results of reading. In addition my reader works with LTP layer and Message layer. It correctly parses/reads folders and messages - no problem with traversing of folders tree and reading messages.

    You know that PST in whole looks like a sandwich or layered pie. Any tiny error in any place or structure brakes all system because everything is very tightly packed and chained. So the correctly working with highest level (folders and messages) code - is a proof of correctness of all underlying things. Can you deny it???

    -- PST build with my code we can successfully read with mentioned above third-party tool and my own code as well.

    I think that errors in NBT/BBT (and NDB layer at all) and things I listed above - can not exist at the same time. Do you agree?

    3. As for scanpst.exe's log - I don't think that here everything is that obvious (my special 'thanks' to developers of this tool). There ain't any reports/confirmations that next step of checking passed successfully. Sort of 'no errors - succeeded'. Maybe I'm wrong - but how to understand?
    http://social.technet.microsoft.com/Forums/en-US/outlook/thread/383f7850-c145-4ed9-a27e-15a68080685c
    No answers. What does it mean?

    So we don't know is the validating of NBT passed or not. And what exactly goes right after NBT checking. Where to find the information??? Can you tall me?
    I would be happy to read sources this tool. But where to get it?

    4. In addition - it's very strange that so easy question
    http://social.technet.microsoft.com/Forums/en-US/outlook/thread/29bcdfd0-1447-49a8-a23b-4949e89e25b0
    does not have answer/solution.
    It makes me think that my questions ain't hard but rather not convenient. And they are simply ignored. What do you think?

    Thank You!

     

     

     

     

    Sunday, December 11, 2011 12:31 AM
  • In the NBT It is normal for NBTENTRY structures to have bidSub and bidParent values of 0x0. The documentation in section 2.2.2.7.7.4 describes what it means if either of those values is 0x0. However, you are correct that it does not appear to be 'normal' that the bidData is also 0x0. I have seen this in my own PST that was generated with Outlook 2010 and I am currently looking further into this. I will let you know when I have more information.

     

    I saw that you did post your question regarding scanpst.exe on the forum that I suggested. Thank you for doing that. However, the person who replied to you on that thread is incorrect in assuming that our group supports that tool. The Open Specifications team does not provide or support any sort of PST parsing or validation tools.

     

    I looked back at your original question regarding the Hierarchy Table Template (2.4.4.4.1) and Contents Table Template (2.4.4.5.1). If you are seeing a difference in the property columns between PST files generated with Outlook 2010 and Outlook 2007 there should be a behavior note about that in the document. I am looking further into this and will let you know when I have more information.

     

    I am still looking into your other issues. Your patience is greatly appreciated.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team
    Friday, December 16, 2011 8:32 PM
    Moderator
  • 1. I know that bidSub and bidParent can be null. No problem with it. But the key is bidData = 0x0. Yes, I inserted the same properties into my own PST. Ok, no problem.
    The matter is that in spec there is nothing about it. So..... what else is not covered in spec??? And how much of undocumented things???

    2. As for scanpst.exe - now it's useless for me. Nothing to do with it. Sources of this tool are able to really help. Is it possible to see sources? Most likely not :(

    3. Yeah, you're absolutely right! It should be!!! I agree with you. And where it is??? Can you point it?

    4. One more question. There is the dump of Named Property Lookup Map (2.4.7) from blank .pst file (created with Outlook 2007/2010).

     

    PC.NID: 0x00000061 DUMP:

    01: ID: 1097, type: 0102, hnid: 00A0, val: bin: len: 16, 05.82.00.00.06.00.00.00.02.81.00.00.0A.00.11.00

    02: ID: 10AE, type: 0102, hnid: 04C0, val: bin: len: 8, 03.85.00.00.08.00.21.00

    03: ID: 109C, type: 0102, hnid: 0140, val: bin: len: 8, 0E.82.00.00.06.00.05.00

    04: ID: 1021, type: 0102, hnid: 0380, val: bin: len: 8, 44.67.49.E2.05.00.17.00

    05: ID: 10E6, type: 0102, hnid: 0560, val: bin: len: 8, 0C.62.E4.8D.05.00.26.00

    06: ID: 1054, type: 0102, hnid: 01E0, val: bin: len: 8, A4.85.00.00.08.00.0A.00

    07: ID: 1094, type: 0102, hnid: 0260, val: bin: len: 16, 0F.81.00.00.0A.00.0E.00.A8.67.22.13.05.00.27.00

    08: ID: 0002, type: 0102, hnid: 0060, val: bin: len: 96, GUID Stream

    09: ID: 1002, type: 0102, hnid: 0540, val: bin: len: 8, 52.85.00.00.08.00.25.00

    10: ID: 1030, type: 0102, hnid: 03E0, val: bin: len: 8, 80.85.00.00.08.00.1A.00

    11: ID: 10C7, type: 0102, hnid: 0160, val: bin: len: 8, 35.82.00.00.06.00.06.00

    12: ID: 109E, type: 0102, hnid: 0220, val: bin: len: 8, 05.81.00.00.0A.00.0C.00

    13: ID: 10CC, type: 0102, hnid: 0360, val: bin: len: 8, 65.8F.00.E6.0F.00.16.00

    14: ID: 1091, type: 0102, hnid: 0300, val: bin: len: 8, 08.81.00.00.0A.00.13.00

    15: ID: 10A8, type: 0102, hnid: 02E0, val: bin: len: 8, 13.81.00.00.0A.00.12.00

    16: ID: 10BF, type: 0102, hnid: 01C0, val: bin: len: 8, 14.85.00.00.08.00.09.00

    17: ID: 10AD, type: 0102, hnid: 0200, val: bin: len: 8, 02.85.00.00.08.00.0B.00

    18: ID: 10C4, type: 0102, hnid: 0180, val: bin: len: 8, 36.82.00.00.06.00.07.00

    19: ID: 0004, type: 0102, hnid: 0280, val: bin: len: 568, String Stream

    20: ID: 10C9, type: 0102, hnid: 01A0, val: bin: len: 8, 33.82.00.00.06.00.08.00

    21: ID: 1020, type: 0102, hnid: 0520, val: bin: len: 8, 70.85.00.00.08.00.24.00

    22: ID: 1065, type: 0102, hnid: 02A0, val: bin: len: 8, 3B.4D.DA.2E.05.00.0F.00

    23: ID: 10A5, type: 0102, hnid: 0320, val: bin: len: 8, 1C.81.00.00.0A.00.14.00

    24: ID: 1013, type: 0102, hnid: 0500, val: bin: len: 8, 7B.94.B1.E9.0F.00.23.00

    25: ID: 1093, type: 0102, hnid: 0340, val: bin: len: 8, 05.80.00.00.0C.00.15.00

    26: ID: 10EA, type: 0102, hnid: 0480, val: bin: len: 8, 05.8F.00.00.10.00.1F.00

    27: ID: 0001, type: 0003, hnid: 00FB, val: int32: 0x000000FB

    28: ID: 1018, type: 0102, hnid: 0460, val: bin: len: 8, 78.85.00.00.08.00.1E.00

    29: ID: 102F, type: 0102, hnid: 0420, val: bin: len: 8, 1F.74.44.FB.05.00.1C.00

    30: ID: 109D, type: 0102, hnid: 0240, val: bin: len: 8, 04.81.00.00.0A.00.0D.00

    31: ID: 10CB, type: 0102, hnid: 00E0, val: bin: len: 8, 31.82.00.00.06.00.02.00

    32: ID: 100B, type: 0102, hnid: 03C0, val: bin: len: 8, 03.F1.BA.A6.0F.00.19.00

    33: ID: 10B9, type: 0102, hnid: 00C0, val: bin: len: 8, 23.82.00.00.06.00.01.00

    34: ID: 10EC, type: 0102, hnid: 04A0, val: bin: len: 8, 07.8F.00.00.10.00.20.00

    35: ID: 0003, type: 0102, hnid: 0080, val: bin: len: 320, Entry Stream

    36: ID: 109A, type: 0102, hnid: 02C0, val: bin: len: 8, 01.81.00.00.0A.00.10.00

    37: ID: 1031, type: 0102, hnid: 0400, val: bin: len: 8, 81.85.00.00.08.00.1B.00

    38: ID: 1048, type: 0102, hnid: 04E0, val: bin: len: 8, A8.85.00.00.08.00.22.00

    39: ID: 109F, type: 0102, hnid: 0120, val: bin: len: 8, 0D.82.00.00.06.00.04.00

    40: ID: 10A4, type: 0102, hnid: 0100, val: bin: len: 8, 16.82.00.00.06.00.03.00

    41: ID: 10BB, type: 0102, hnid: 0440, val: bin: len: 8, 10.85.00.00.08.00.1D.00

    42: ID: 10E9, type: 0102, hnid: 03A0, val: bin: len: 8, B3.8A.B1.64.0F.00.18.00

    As you can see - it's far from empty or from containing only one property as it stated in spec. These records belongs to BTH the PC is based on.
    What this table means. Let's consider first line.

    01: ID: 1097, type: 0102, hnid: 00A0, val: bin: len: 16, 05.82.00.00.06.00.00.00.02.81.00.00.0A.00.11.00

    01 - this is ordinal number of entry in map
    ID: 1097 - 0x1097 - property ID (wPropID - see 2.3.3.3)
    type: 0102 - type of property (wPropType) (0x0102 - binary, 0x0003 - int32)
    hnid: 00A0 - dwValueHnid.
    val: bin: len: 16 - type of value - bin = binary. len - is length of value in bytes.
    05.82.00.00.06.00.00.00.02.81.00.00.0A.00.11.00 - 16 bytes representing the very value
    The problem is that most of propID are unknown. Try to find propTag = 0x10970102 (0x + propID + propType). Google does not know anything about it. Search thru MS-XXXX.pdf specs - gives nothing. Or maybe I'm searching wrong places and wrong pdf's???
    For example try to google well known property: propTag = 0x3001001f.
    It works! You can see references on this value: PR_DISPLAY_NAME = '3001001F'. .... and so on.
    At the same time try to find:
    Nothing related. What I'm doing wrong?
    What these properties are??? Where in spec is said about them?
    Most of them have size 8 bytes - probably this is dateTime?
    Several ones are 16 bytes - maybe these are GUIDs.... 
    But what the spec says about it?????

     

     


    • Edited by committed Sunday, December 18, 2011 12:49 AM
    Sunday, December 18, 2011 12:47 AM
  • Hi committed, I am still looking into this issue. I hope to have more information for you soon. Your patience is greatly appreciated.
    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team
    • Marked as answer by committed Saturday, February 25, 2012 12:01 PM
    • Unmarked as answer by committed Saturday, February 25, 2012 12:01 PM
    Tuesday, January 3, 2012 4:32 PM
    Moderator
  • Hi committed, here is an update on where I am with your various issue…

     

    Hierarchy Table Template (2.4.4.4.1) and Contents Table Template (2.4.4.5.1)

    The properties listed in the current documentation are what is created by Outlook 2010 by default. However, only a subset of those properties are required in a new PST and Outlook may add other properties as necessary. Unless you are missing any of the required properties, this is probably not what is causing your PST file to be unreadable by Outlook. This information may be included in a future release of the document.

     

    Hierarchy Table Template Required Property Columns:

    "0x3001" pr_display_name

    "0x3602" pr_content_count

    "0x3603" pr_content_unread

    "0x360A" pr_subfolders

    "0x3613" pr_container_class

    "0x67F2" pr_ltp_row_id

    "0x67F3" pr_ltp_row_ver

     

    Contents Table Template Required Property Columns:

    "0x17" pr_importance

    "0x1A" pr_message_class

    "0x36" pr_sensitivity

    "0x37" pr_subject

    "0x42" pr_sent_representing_name

    "0x57" pr_message_to_me

    "0x58" pr_message_cc_me

    "0xE03" pr_display_cc

    "0xE04" pr_display_to

    "0xE06" pr_message_delivery_time

    "0xE07" pr_message_flags

    "0xE08" pr_message_size

    "0xE17" pr_msg_status

    "0x67F2" pr_ltp_row_id

    "0x67F3" pr_ltp_row_ver

     

     

    NID's that contain empty (0x0) bidData values:

    Outlook allocates the NID and places an entry in the Node BTree as a place holder but there's no data associated with that NID type yet, so there's no data block to point to. The bidData value will be 0x0 when this is the case and is the expected behavior.

     

     

    Named Property Lookup Map:

    The values that you see in the Named Property Lookup Map are created as needed and are not required in a PST created from scratch. You will not be able to search for those on the web because they are created dynamically by the client. Please review section 2.4.2.2 for more information. This is not what is causing your PST file to be unreadable by Outlook.

     

    Please let me know if you have any other questions.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team
    Friday, January 20, 2012 8:57 PM
    Moderator
  • Thank you, JCurry, for you explanations.

    Could you give me exact answer on the following questions.

    1. Obviously that compliance with specification - is necessary condition for building fully correct pst-file that will be correctly opened with Outlook.
    That's true?

    2. Section 2.7 "Minimum PST Requirements" - can be treated as sufficient condition for building pst-file that will be successfully opened with Outlook???

    In other words - can it be so that Outlook meets all spec requirements ... AND in addition has some implementation-specific (probably stronger than in spec) requirements/expectations about internals of pst-file???

    Thank You very much in advance.... and looking forward to your reply.

    Saturday, February 25, 2012 1:12 PM
  • Hi committed, I will look into this and let you know what I find out. Your patience is greatly appreciated.



    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Saturday, February 25, 2012 10:04 PM
    Moderator
  • Hi Committed, the entire specification describes each data structure in detail, how they’re laid out on disk, and how they must be internally consistent. Section 2.7 describes specific instances of those data structures which must exist in order for a store (PST) to be proper.  It also contains considerable details on the types of NIDs, folder hierarchy, required properties, etc. that are all required to meet the minimum PST requirements. You should have all of the information you need to build a functioning PST file that can be read by Outlook.

    If you would like to send me your PST file we might be able to figure out if the spec is missing some required information or if your file does not match the spec. You can send that to me at the following address and reference this thread. dochelp(at)microsoft(dot)com


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Monday, March 5, 2012 9:56 PM
    Moderator
  • Hi, JCurry!

    Please, try to answer on my 3 simple 'yes/no' questions from previous post, if it's possible, in the same manner - I mean 'yes/no'. If it will not be so difficult for you.

    Thank you for help - I've sent my .pst-file to you and looking forward to your reply - what's wrong with my file.

    Thank You one more time.

    Tuesday, March 6, 2012 7:40 AM
  • Hi Committed, I received your PST file via e-mail. Thank you for that.

    The answer to each of your previous questions in 'Yes'.

     1. Your PST file MUST comply with the documented specification.
     2. Your PST file MUST contain the minimum requirements as specified in section 2.7
     3. When Outlook creates a PST file it contains everything specified in Section 2.7 and a lot of additional 'stuff'. However, your PST file is not expected to contain all of that extra 'stuff'. Outlook will add most of it when it opens the file for the first time provided that the file contains the minimum requirements and is structured correctly.
     
    Please give me some time to review your PST file. I will let you know when I have more information.

    Thank you.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Tuesday, March 6, 2012 3:32 PM
    Moderator
  • Hi, Josh.

    I have one more question. Be so kind - pls, make it clear.

    Can different properties (that are identified with 32-bit property tag = 16bit propertyID + 16bit propertyType) share the same propertyID???

    OR propertyID identifies certain property unambiguously???

    The thing is I see in spec two completely distinct property with the same propID value.

    I mean:

    1. PidTagNameidBucketBase (propID: 0x1000, propType: PtypBinary)

    2. PidTagBody (propID: 0x1000, propType: PtypString)

    It's very important for me qoz it does change many things.

    What the specification, document, RFC (or whatever else) clearly describes the nature and properties of propertyTag?

    A lot of thanks in advance!

    Wednesday, June 13, 2012 8:44 AM
  • Hi committed, I am looking into this issue. I hope to have more information for you soon. Your patience is greatly appreciated.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Thursday, June 14, 2012 1:58 PM
    Moderator
  • Those properties are on two different objects, so there is no conflict with them both having the same property ID. So the answer to your first question is yes. As to your second question, it's unclear what you mean when you say "unambiguous". Given an object and given a property tag, that property tag will always fetch the same property from the object. However, two different object can assign different meanings to the same property tag, as in the example you noted.

    Context is the key. To give an example not involving the PST spec, consider the property 0x68470003. When found on a search folder definition message, this is PidTagSearchFolderTag. If we find the same property on a free busy message, this property is PidTagFreeBusyPublishStart. There are several other examples.

    PidTagNameidBucketBase is defined in a context where PidTagBody is not defined, so if their propertyIDs are the same this does not matter.

    The basic structure of a property tag is defined here but I suspect that's not what you were looking for. In short, a property tag is just a number combining an ID and type. The context in which the tag is used is what determines what the ID actually means.

    Friday, June 15, 2012 1:41 PM
  • 1. You're referencing to some kind of 'object'. What do you mean exactly in this context??? What is object in MAPI-world??? HN? BT? PC? TC? Message? Folder? Attachment?

    So there is not any sense in term 'object' that you refer to unless there is not any EXACT definition of this term in respect to domain we're talking about.

    2. As for you question about "unambiguous". Let's consider example such as Windows Error Code. If i'm working on the windows platform and I've got error with code '5' - I know that this error is 'access denied'. So there are three parts: a) platform (win) b) entity (error) c) numeric value (5). All this allows me to identify situation in _unambiguous_ manner - we have 'access denied'.

    Let's get back to the propertyTag. What we need to know to definitely identify property if we have propertyID 16bit value??? You say that we have to know in addition some kind object or context of this propertyID. But no one of definition propertyTag/propertyID does not say about it. And even the URL you gave.

    3. What's about this case (here we have... apparently the same so say 'object')

    2.680 PidTagBodyHtml
    Canonical name: PidTagBodyHtml
    Property ID: 0x1013
    Data type: PtypString, 0x001F
    Area: General Message Properties
    Defining reference: [MS-OXCMSG] section 2.2.1.48.3
    Consuming references: [MS-OXCFXICS], [MS-OXCICAL], [MS-OXOMSG], [MS-OXORMMS], [MS-OXRTFEX]
    Alternate names: PR_BODY_HTML, PR_BODY_HTML_A, ptagBodyHtml, PR_BODY_HTML_W

    2.792 PidTagHtml
    Canonical name: PidTagHtml
    Description: Contains message body text in HTML format.
    Property ID: 0x1013
    Data type: PtypBinary, 0x0102
    Area: General Message Properties
    Defining reference: [MS-OXCMSG] section 2.2.1.48.9
    Consuming references: [MS-OXBBODY], [MS-OXCMAIL], [MS-OXOPOST], [MS-OXORMMS], [MS-OXORSS], [MS-OXOSMMS]
    Alternate names: PR_HTML, ptagHtml

    I found it in ms-oxprops.pdf.

    What part of this definitions plays the role of 'object'???

    Thank You!

    Friday, June 15, 2012 3:04 PM
  • Hi committed, I meant to post this yesterday. Stephen is correct about the context of the properties. Let me try to explain it in a different way.

    The Exchange Server Protocols Master Property List [MS-OXPROPS]contains information about most of the properties. However, not all properties, such as PidTagNameidBucketBase, are documented in that list.

    Per section 1, "The criteria for including a property in the Exchange Server Protocols documentation are that it is set by a client in order to affect server behavior, or that it is set by a server in order to affect client behavior. Properties that are merely stored by the server on behalf of the client, or generated by the server for its own use and ignored by the client, are not necessarily documented."

    PidTagBody applies to message objects and can be found in MS-OXPROPS section 2.692. PidTagNameidBucketBase doesn't meet the criteria from section 1 because it only exists in MS-PST. It's not a property that is exchanged between the client and server. PidTagNameidBucketBase is only mentioned in MS-PST section 2.4.7.5 and only applies to the Hash Table for the Named Property Lookup Map.

    While the 2 properties share the same Property ID, they live in completely different contexts. It's not possible for them to conflict or be confused with one another.

    Here is another thread that discusses why you might encounter two properties that share the same Property ID. http://social.msdn.microsoft.com/Forums/en/os_exchangeprotocols/thread/15b9fca5-ebbb-4b71-9b74-f862a18de5b6

    Please let me know if this helps.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Friday, June 15, 2012 3:53 PM
    Moderator
  • Nice! It's more-less clear.

    Then what's about this case (here we have... apparently the same so say 'object')

    2.680 PidTagBodyHtml
    Canonical name: PidTagBodyHtml
    Property ID: 0x1013
    Data type: PtypString, 0x001F
    Area: General Message Properties
    Defining reference: [MS-OXCMSG] section 2.2.1.48.3
    Consuming references: [MS-OXCFXICS], [MS-OXCICAL], [MS-OXOMSG], [MS-OXORMMS], [MS-OXRTFEX]
    Alternate names: PR_BODY_HTML, PR_BODY_HTML_A, ptagBodyHtml, PR_BODY_HTML_W

    2.792 PidTagHtml
    Canonical name: PidTagHtml
    Description: Contains message body text in HTML format.
    Property ID: 0x1013
    Data type: PtypBinary, 0x0102
    Area: General Message Properties
    Defining reference: [MS-OXCMSG] section 2.2.1.48.9
    Consuming references: [MS-OXBBODY], [MS-OXCMAIL], [MS-OXOPOST], [MS-OXORMMS], [MS-OXORSS], [MS-OXOSMMS]
    Alternate names: PR_HTML, ptagHtml

    I found it in ms-oxprops.pdf.

    What part of these definitions plays the role of 'object'???

    Thank You!


    Friday, June 15, 2012 8:51 PM
  • The difference in those two properties is the property type. They're asking for the same basic property, but in two different formats. The first one would be used to ask for a unicode string/stream (depending on whether this is used in GetProps or OpenProperty). The second is used for a binary blob/stream. The expectation here is the same underlying storage is consulted for either property, and whatever conversion needs to happen to serve the property is performed by the provider.

    It's not unusual to see property definitions such as this for both a string (ANSI, Unicode, or both) and binary, especially for properties such as the body which have an expectation of being large. Much more common though is that most string properties can be requested by MAPI clients as either PT_UNICODE or PT_STRING8, with MAPI and the underlying provider translating as needed.

    I may have confused you when I said object earlier - I was speaking generically about whatever "thing" you're requesting the property from. This "thing" or "object" could be anything - a message, an attachment, a recipient, a message store, a profile section, etc. From the perspective of a MAPI client, this would typically be something inheriting from IMAPIProp. For this body property, the object would be a message, specifically an object inheriting from IMessage.

    If you haven't already, you should take a look at MFCMAPI. With this tool, you can explore MAPI and familiarize yourself better with the nature of MAPI properties and the relationships between most MAPI objects.

    Saturday, June 16, 2012 6:05 AM
  • It's absolutely obvious that these two definition have different type. I would't ask about it. The question was about sharing propID in the same context.

    The main idea is the propertyID does not identify property as it said in documentation. Moreover - propertyID can't identify property even if we're saying about the same object/thing/area/context/domain/whatever.

    It's not a big deal to correct my source code to take into account the real nature of propertyTag. It's pity that MS's docs don't try to be clear and exhaustive. I don't think that clear explanation of meaning and properties of 32bit value is beyond MS's strength.

    Saturday, June 16, 2012 7:19 AM
  • The property ID in this context (IE - on a message) absolutely identifies the property being requested, and the type identifies the type it is being requested as. The expectation is that either type is served from the same underlying data. We would not expect, for example, for the streams retrieved using PidTagBodyHtml and PidTagHtml to represent two different data sources. In fact, if they did represent two different data sources, that would be a bug in the provider. A change to one should always be reflected in the other (on re-read of course).

    Incidently, the relationship between the various body properties is documented extensively in the Best Body Protocol documentation and MS-OXCMSG. Could you point at a specific section you believe is not clear?

    Saturday, June 16, 2012 8:23 PM