• Sign In
 
  • MSDN Blogs
  • Microsoft Blog Images
  • More ...

  • Advanced search options...
  • About
  • Email Blog Author
  • RSS for posts
  • Atom
  • RSS for comments
    • OK
  • CDO (20)
  • Code Snippet (42)
  • Custom Providers (15)
  • Debugging (7)
  • DevMsgTeam (278)
  • Documentation (101)
  • DST (8)
  • EWS (7)
  • Exchange (100)
  • Gotchas (91)
  • Hotfix (28)
  • MAPI (220)
  • MAPI Download (48)
  • MFCMAPI (92)
  • MSDN (54)
  • Non Dev (11)
  • OOM (17)
  • Outlook (163)
  • Outlook 2007 Auxiliary Reference (45)
  • Outlook Integration API (11)
  • Protocol Docs (20)
  • PST/OST (22)
  • Referrals (8)
  • Vista (12)
  • WrapPST (15)
Links:
  • Download MFCMAPI
  • MFCMAPI on Facebook
  • Troubleshooting Outlook Crashes
  • Office Update Center
  • Developer Messaging Team Blog
This site is provided "AS IS" with no warranties, and confers no rights. Use of included code samples are subject to the terms specified in the Terms of Use.
Archives
  • May 2012 (1)
  • April 2012 (3)
  • March 2012 (3)
  • February 2012 (3)
  • January 2012 (1)
  • December 2011 (3)
  • November 2011 (1)
  • October 2011 (3)
  • September 2011 (1)
  • August 2011 (1)
  • July 2011 (4)
  • June 2011 (3)
  • May 2011 (3)
  • April 2011 (3)
  • March 2011 (5)
  • February 2011 (1)
  • January 2011 (2)
  • December 2010 (1)
  • November 2010 (4)
  • October 2010 (1)
  • September 2010 (3)
  • August 2010 (5)
  • July 2010 (3)
  • June 2010 (3)
  • May 2010 (1)
  • April 2010 (3)
  • March 2010 (3)
  • February 2010 (3)
  • January 2010 (2)
  • December 2009 (3)
  • November 2009 (5)
  • October 2009 (4)
  • September 2009 (5)
  • August 2009 (5)
  • July 2009 (11)
  • June 2009 (6)
  • May 2009 (5)
  • April 2009 (3)
  • March 2009 (18)
  • February 2009 (10)
  • January 2009 (3)
  • December 2008 (2)
  • November 2008 (2)
  • October 2008 (5)
  • September 2008 (4)
  • August 2008 (10)
  • July 2008 (6)
  • June 2008 (8)
  • May 2008 (2)
  • April 2008 (4)
  • March 2008 (2)
  • February 2008 (2)
  • January 2008 (5)
  • December 2007 (3)
  • November 2007 (2)
  • October 2007 (3)
  • September 2007 (1)
  • August 2007 (4)
  • July 2007 (5)
  • June 2007 (3)
  • May 2007 (4)
  • April 2007 (1)
  • March 2007 (6)
  • February 2007 (3)
  • January 2007 (2)
  • December 2006 (4)
  • November 2006 (3)
  • October 2006 (1)
  • August 2006 (1)
  • June 2006 (5)
  • May 2006 (5)
  • December 2005 (1)
  • November 2005 (4)
  • October 2005 (2)
  • September 2005 (1)
  • April 2005 (3)
  • December 2004 (2)
  • September 2004 (2)
  • August 2004 (3)
  • July 2004 (3)
Blogs I Read
  • Exchange

  • Raymond Chen [MSFT]

  • Larry Osterman [MSFT]

  • Peter David

  • Aaron Margosis [MSFT]

  • Jason Johnston [MSFT]

  • Matt Stehle (MSFT)

  • Patrick Creehan [MSFT]

  • Ryan Gregg [MSFT]

    Outlook PM
  • WebDav 101

    Dan Bagley (MSFT)
  • Dave Vespa [MSFT]

  • Randy Topken

    Outlook EE

March, 2007

MSDN Blogs > SGriffin's MAPI Internals > March, 2007
  • Subscribe via RSS
Sort by: Most Recent | Most Views | Most Comments
Excerpt View | Full Post View
  • SGriffin's MAPI Internals

    Why Can't I Open The Mailbox?

    Posted over 5 years ago
    by Stephen Griffin - MSFT
    • 4 Comments

     

    Following up on my previous article on CONNECT_IGNORE_NO_PF, I had a customer recently who claimed MAPI didn't work if there is no Public Folder store. They kept getting MAPI_E_FAILONEPROVIDER when they tried to open the message store. I pointed them to CONNECT_IGNORE_NO_PF, but they were aware of it and insisted they were setting it right. They even showed my their code, and I confirmed that they were setting it. I didn't quite trust their code, so I used MFCMAPI to test. Sure enough - on a brand new lab setup with no Public Folder store, I saw the same thing they did!

    What the customer was doing running their code as the Administrator account, and trying to log on to another mailbox. We'll call that one Bart Simpson (bsimpson). The key to solving this issue was when I realized I could log on to Administrator's mailbox just fine, and even jump from there into Bart's mailbox - it was only when I created a profile for Bart and tried to use it that I got the error. Maybe it's just rights?

    Here were the permissions Administrator had to Bart's mailbox:

    [PS] C:\>get-MailboxPermission -identity bsimpson -User administrator |fl
    AccessRights : {FullAccess}
    Deny : True
    InheritanceType : All
    User : MyDOM\Administrator
    Identity : MyDOM.extest.microsoft.com/Users/Bart Simpson
    IsInherited : True
    IsValid : True
    ObjectState : Unchanged 
    
    AccessRights : {FullAccess, DeleteItem, ReadPermission,
    ChangePermission, ChangeOwner}
    Deny : False
    InheritanceType : All
    User : MyDOM\Administrator
    Identity : MyDOM.extest.microsoft.com/Users/Bart Simpson
    IsInherited : True
    IsValid : True
    ObjectState : Unchanged 

    Note the deny there on the FullAccess right! Well no wonder I couldn't open the mailbox!

    There are two ways to resolve this:

    1. The way I recommend to log into multiple mailboxes for server applications is to use a single profile and log on to an administrative mailbox first. Then use CreateStoreEntryID with the OPENSTORE_USE_ADMIN_PRIVILEGE parameter to create an entry ID to use with OpenMsgStore. This technique is illustrated in MFCMAPI.

      When you log on to the BSimpson mailbox this way, Exchange spots the OPENSTORE_USE_ADMIN_PRIVILEGE flag and bypasses the check for full access rights, instead relying on the user's inherited administrative rights. This is the preferred mechanism to log on to mailboxes as it is (slightly) less resource intensive and (much) less error prone than creating new profiles for each mailbox. If you're following along in MFCMAPI, use MDB/Open Other User's Mailbox or MDB/GetMailboxTable to try this out.
    2. If you must create a new profile, you need to grant Administrator the Full Access right to bsimpson's mailbox. Here's a powershell command to do this:
      [PS] C:\>Add-MailboxPermission -identity bsimpson -accessRights fullAccess -User administrator |fl
      AccessRights : {FullAccess}
      Deny : False
      InheritanceType : All
      User : MyDOM\Administrator
      Identity : MyDOM.extest.microsoft.com/Users/Bart Simpson
      IsInherited : False
      IsValid : True
      ObjectState : Unchanged 

      After we do this, the permissions will look like this:
      [PS] C:\>get-MailboxPermission -identity bsimpson -User administrator |fl
      AccessRights : {FullAccess}
      Deny : False
      InheritanceType : All
      User : MyDOM\Administrator
      Identity : MyDOM.extest.microsoft.com/Users/Bart Simpson
      IsInherited : False
      IsValid : True
      ObjectState : Unchanged 
      AccessRights : {FullAccess}
      Deny : True
      InheritanceType : All
      User : MyDOM\Administrator
      Identity : MyDOM.extest.microsoft.com/Users/Bart Simpson
      IsInherited : True
      IsValid : True
      ObjectState : Unchanged 
      
      AccessRights : {FullAccess, DeleteItem, ReadPermission,
      ChangePermission, ChangeOwner}
      Deny : False
      InheritanceType : All
      User : MyDOM\Administrator
      Identity : MyDOM.extest.microsoft.com/Users/Bart Simpson
      IsInherited : True
      IsValid : True
      ObjectState : Unchanged
      And the allow will supercede the deny. Assuming CONNECT_IGNORE_NO_PF is set properly, the logon should succeed.

    Now - what was wild about this case was that even after granting the rights, the customer was still getting MAPI_E_FAILONEPROVIDER when connecting to an Exchange 2007 server that had no Public Folders. Even when they tried to log on to Administrator's mailbox while running as Administrator they got the error.

    This prompted another, much closer, look at the source code they had sent me, where I realized they were trying to open the first message store in the message store table, which happened to be the Public Folder store. Well of course that's going to fail!

    After removing this call, everything worked as described.

    FURTHER READING
    The way permissions work here didn't change in Exchange 2007. Here are some articles documenting it for Exchange 2003 and 2000:
    How to configure an account to use the ExMerge utility in Exchange 2000 Server and in Exchange Server 2003
    How to assign service account access to all mailboxes in Exchange Server 2003

  • SGriffin's MAPI Internals

    MAPI and Exchange 2007

    Posted over 5 years ago
    by Stephen Griffin - MSFT
    • 43 Comments

    Most of you have realized by now that Exchange 2007 doesn't include MAPI "in the box". We're supporting two ways to put MAPI on an Exchange 2007 server:

    • The MAPI Download
    • Outlook 2007

    Some of you have noticed as well that with Exchange 2007, you don't have to have a Public Folder store. What happens when you try to connect to an Exchange 2007 server that doesn't have a Public Folder store?

    With Outlook 2007, you connect with no problem. Earlier versions of Outlook get this error:

    "Your Exchange Server administrator has blocked the version of Outlook that you are using. Contact your administrator for assistance."

    MAPI applications will get the error MAPI_E_FAILONEPROVIDER if they're using any version of MAPI except the version supplied by Outlook 2007.

    So what's a developer to do? Are you locked in to Outlook 2007's MAPI? Why did we provide a MAPI download if it won't even work?

    Introducing CONNECT_IGNORE_NO_PF

    Exchange 2007 blocks all MAPI providers earlier than Outlook 2007 when Public Folders are not available. This is because all of the earlier clients assume Public Folders will be available and will experience failures if allowed to connect. For customers whose code does not depend on Public Folders, a new flag has been made available to allow this check to be bypassed.

    Right now, the only version of MAPI which supports this new flag is the MAPI download.

    Details on the new flag:

    #define CONNECT_IGNORE_NO_PF ((ULONG)0x8000)

    This is set in the PR_PROFILE_CONNECT_FLAGS property on the global profile section.

    The global profile section can be accessed by calling OpenProfileSection with pbGlobalProfileSectionGuid, which is defined in edkmdb.h.

    When this flag is set, Exchange 2007 will not check if public folders are available when logging on. Use of this flag can be demonstrated with MAPI Editor:

    1. Install the new MAPI download
    2. In MAPI Editor, do Profile/Show Profiles and open the profile you wish to work on
    3. Locate the MSEMS service and open it
    4. Locate the profile section with the PR_PROVIDER_UID of 13DBB0C8AA05101A9BB000AA002FC45A and single click on it
    5. In the lower pane, locate PR_PROFILE_CONNECT_FLAGS
    6. Edit this property to OR in the new flag. So for instance, if it previously had 0x2 in there, it would now have 0x8002
    7. Close all the profile windows and attempt to log on

    Caveats

    • Even with this flag you won't be able to use Public Folders (they don't exist) so any errors attempting to open or reference them would be expected.
    • Both the client side MAPI binaries and the Exchange store need to be aware of the flag for it to work.
    • Builds of MAPI that understand this flag are the one from the download only and Exchange 2003 06.05.09.7652 or higher (KB 929751)
    • Builds of the Exchange store that understand this flag are Exchange 2007 and Exchange 2003 06.05.09.7652 or higher (KB 929751)
    • The build of CDO included in the download will automatically set this flag on dynamic profiles.
    • Previous versions of Exchange may not understand this flag, so be sure only to set it when logging on to an Exchange 2007 mailbox.

    Update - 4/17/07 Removed inadvertent assertion that there is a build of Exchange 2003 MAPI that understands this flag. If such a build does become available I'll update again.

  • SGriffin's MAPI Internals

    Outlook 2007 RTM Docs - List of provider GUIDs set in the registry

    Posted over 5 years ago
    by Stephen Griffin - MSFT
    • 1 Comments

    [This is now documented here: http://msdn.microsoft.com/en-us/library/bb821125.aspx] 

    (Now that Outlook 2007 is available I'm reposting some of the articles from the Outlook 2007 Beta Documentation series. Some of the articles are virtually unchanged, others are completely different to reflect the differences between Beta and RTM. This article finishes the rewrite of Outlook 2007 Beta Documentation - Notification Based Indexing Support.)

    The MAPI PH consults the registry to determine which MAPI providers should be indexed. Any provider not listed in the registry will not be indexed by the MAPI PH.

    Outlook adds the following 4 providers to the registry to enable indexing if the policy allows it:

    • PST store
    • Exchange (including offline store - OST)
    • Public Folder stores
    • Outlook MSN Connector

    Third party providers which wish to be indexed will need to list themselves in the registry.

    The MAPI PH will check the following registry values:

    • [HKLM]\Software\Policies\Microsoft\Windows\Windows Search\[GUID=dword:1]
    • [HKLM]\Software\Microsoft\Windows\Windows Search\Preferences\[GUID=dword:1]
    • [HKCU]\Software\Microsoft\Windows\Windows Search\Preferences\[GUID=dword:1]

    Only one value has to be set and they are checked in the order shown above.

    When the MAPI PH is installed, the default providers are configured as follows:

    Windows Registry Editor Version 5.00 
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Search\Preferences] 
    "{4154494E-BFF9-01B8-00AA-0037D96E0000}"=dword:00000001
    "{C0A19454-7F29-1B10-A587-08002B2A2517}"=dword:00000001
    "{70fab278-f7af-cd11-9bc8-00aa002fc45a}"=dword:00000001
    "{c34f5c97-eb05-bb4b-b199-2a7570ec7cf9}"=dword:00000001

    The guids shown are the PR_MDB_PROVIDER properties for the stores. The first three provider guids have previously been documented in header files as MSPST_UID_PROVIDER, pbExchangeProviderPrimaryUserGuid, and pbExchangeProviderPublicGuid.

  • SGriffin's MAPI Internals

    Outlook 2007 RTM Docs - Properties

    Posted over 5 years ago
    by Stephen Griffin - MSFT
    • 16 Comments

    [This is now documented here: http://msdn.microsoft.com/en-us/library/bb927656.aspx, http://msdn.microsoft.com/en-us/library/bb905130.aspx, http://msdn.microsoft.com/en-us/library/bb821179.aspx]

    (Now that Outlook 2007 is available I'm reposting some of the articles from the Outlook 2007 Beta Documentation series. Some of the articles are virtually unchanged, others are completely different to reflect the differences between Beta and RTM. This article is the updated version of the second half of Outlook 2007 Beta Documentation - Notification Based Indexing Support.)

    New properties used by the MAPI PH

    #define PR_PROVIDER_ITEMID           PROP_TAG(PT_BINARY,  0x0EA3)
    #define PR_PROVIDER_PARENT_ITEMID    PROP_TAG(PT_BINARY,  0x0EA4)
    These properties are used to identify an item or a folder by the store provider. They are retrieved when the store provider gets the search results from the search engine and are used to identify which items matched the query. Store providers can provide provider specific values for these properties but their values shouldn’t change between sessions otherwise they won’t know how to map the items when getting search results.
    #define PR_SEARCH_OWNER_ID           PROP_TAG(PT_LONG,    0x3419)
    Used by the MAPI PH to know which process is pushing URLs to be indexed.
    #define PR_ADDITIONAL_REN_ENTRYIDS    PROP_TAG(PT_MV_BINARY, 0x36D8)
    This is a multivalued property which contains entry IDs for certain special folders. The first 5 (0-4) entries in this multivalued property are as follows:
    0 - Conflicts folder
    1 - Sync Issues folder
    2 - Local Failures folder
    3 - Server Failures folder
    4 - Junk E-mail Folder

    The following properties are used in MAPI restrictions:

    #define PR_SEARCH_ATTACHMENTS_W      PROP_TAG(PT_UNICODE, 0x0EA5) 
    Used when searching for attachment contents.
    #define PR_SEARCH_RECIP_EMAIL_TO_W   PROP_TAG(PT_UNICODE, 0x0EA6)
    Used when searching for email address or display names the message was sent to.
    #define PR_SEARCH_RECIP_EMAIL_CC_W   PROP_TAG(PT_UNICODE, 0x0EA7)
    Used when searching for email address or display names the message was Cc’ed.
    #define PR_SEARCH_RECIP_EMAIL_BCC_W  PROP_TAG(PT_UNICODE, 0x0EA8)
    Used when searching for email address or display names the message was Bcc’ed. This is only interesting for messages not yet sent otherwise the BCC information will not be there.

    Named properties used by the MAPI PH

    The following named properties are indexed by the MAPI PH. These properties are documented as read-only. They should not be used to create or modify items.

    These GUIDs represent the name spaces of the named properties

    const GUID PSETID_Appointment   = {0x00062002, 0x0000, 0x0000, {0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46}};
    const GUID PSETID_Task          = {0x00062003, 0x0000, 0x0000, {0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46}};
    const GUID PSETID_Address       = {0x00062004, 0x0000, 0x0000, {0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46}};
    const GUID PSETID_Common        = {0x00062008, 0x0000, 0x0000, {0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46}};
    const GUID PSETID_Log           = {0x0006200A, 0x0000, 0x0000, {0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46}};
    const GUID PS_PUBLIC_STRINGS    = {0x00020329, 0x0000, 0x0000, {0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46}};
    const GUID PS_INTERNET_HEADERS  = {0x00020386, 0x0000, 0x0000, {0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46}};

    MNID_ID properties:

    // In PSETID_Address
    #define dispidWorkAddressStreet 0x8045
    #define dispidWorkAddressCity 0x8046
    #define dispidWorkAddressState 0x8047
    #define dispidWorkAddressPostalCode 0x8048
    #define dispidWorkAddressCountry 0x8049
    #define dispidInstMsg 0x8062
    #define dispidEmailDisplayName 0x8080
    #define dispidEmailOriginalDisplayName 0x8084
    
    // In PSETID_Task
    #define dispidTaskStartDate 0x8104
    #define dispidTaskDueDate 0x8105
    #define dispidTaskActualEffort 0x8110
    #define dispidTaskEstimatedEffort 0x8111
    #define dispidTaskFRecur 0x8126
    
    // In PSETID_Appointment
    #define dispidLocation 0x8208
    #define dispidApptStartWhole 0x820D
    #define dispidApptEndWhole 0x820E
    #define dispidApptDuration 0x8213
    #define dispidRecurring 0x8223
    #define dispidAllAttendeesString 0x8238
    #define dispidToAttendeesString 0x823B
    #define dispidCCAttendeesString 0x823C
    
    // In PSETID_Common
    #define dispidReminderSet 0x8503
    #define dispidSmartNoAttach 0x8514
    #define dispidCommonStart 0x8516
    #define dispidCommonEnd 0x8517
    #define dispidRequest 0x8530
    #define dispidCompanies 0x8539
    #define dispidReminderNextTime 0x8560
    
    // In PSETID_Log (also known as Journal)
    #define dispidLogType 0x8700
    #define dispidLogStart 0x8706
    #define dispidLogDuration 0x8707
    #define dispidLogEnd 0x8708

    MNID_STRING properties

    // In PS_PUBLIC_STRINGS 
    "Keywords" 
    
    // In PS_INTERNET_HEADERS
    "return-path"
  • SGriffin's MAPI Internals

    Outlook 2007 RTM Docs - Notification Based Indexing Support

    Posted over 5 years ago
    by Stephen Griffin - MSFT
    • 9 Comments

    [This is now documented here: http://msdn.microsoft.com/en-us/library/bb821096.aspx, http://msdn.microsoft.com/en-us/library/bb821097.aspx, http://msdn.microsoft.com/en-us/library/bb821099.aspx, http://msdn.microsoft.com/en-us/library/bb821100.aspx]

    (Now that Outlook 2007 is available I'm reposting some of the articles from the Outlook 2007 Beta Documentation series. Some of the articles are virtually unchanged, others are completely different to reflect the differences between Beta and RTM. This article is the updated version of the first half of Outlook 2007 Beta Documentation - Notification Based Indexing Support.)

    New flag that identifies stores as using Pusher model when indexing

    This flag is set by pusher stores.

    Definition

    #define STORE_PUSHER_OK ((ULONG) 0x00800000)

    If the store provider sets this flag the MAPI PH won’t crawl the store and the store is responsible to push any changes through notifications to the indexer to have messages indexed.

    Usage

    This flag can be retrieved by getting the property PR_STORE_SUPPORT_MASK from the store.

    MAPI URLs

    Every time a folder, message or an attachment is to be indexed a unique Unicode URL has to be generated and sent to the indexer. This URL will later be used to identify which object to be indexed in the MAPI PH that runs in the Search Protocol Host. Store providers are responsible for generating these URLs.

    MAPI URLs have the following format:

    Mapi://SID/StoreDisplayName ($HashNumber)/StoreType/FolderNameA/…/FolderNameN/[EntryIDEncoded[/at=AttachIDEncoded:FileName]]

    Parameters

    SID

    Current user’s SID

    HashNumber

    DWORD in hex calculated based on the store entry id or the store mapping signature. This value will be stored in the registry and will be used later to identify the store in the MAPI PH.

    This number has to be calculated in a way that minimizes collisions between other stores. See below for the algorithm Outlook uses to calculate the hash.

    StoreType

    Number that identifies the type of the store that contains the object to be indexed. Here are the possible values:

    0 – Default store

    1 – Delegate store (used for delegate items cached locally)

    2 – Public Folders (used for public folder favorites)

    Note that if the store is being crawled instead of pushed the value used is none of the above but instead it will be the character X.

    FolderNameA/…/FolderNameN

    The path from the root of the IPM_SUBTREE to the folder or message. For instance, a message in the “Family” folder under “Inbox” will have Inbox/Family for this parameter.

    EntryIDEncoded

    MAPI Entry ID for the item encoded as a Unicode string. See below for how it gets encoded. Note that when viewed as text, this encoded entry ID will appear as random Hangul characters or boxes depending on available fonts.

    AttachIDEncoded

    Attachment ID encoded as a Unicode string.

    FileName

    Attachment file name as it appears in the message.

    Here are some examples of MAPI URLs for a folder, message and attachment respectively:

    mapi://S-1-5-21-2127521184-1604012920-1887927527-71418/Mailbox – Some User ($be19928f)/2/Office

    mapi://S-1-5-21-2127521184-1604012920-1887927527-71418/Mailbox – Some User ($484efb89)/0/Calendar/곯가가가걍걝걌곌겷걢곒갑겛개가검걟곔걙곾걤곂갠가

    mapi://S-1-5-21-2127521184-1604012920-1887927527-71418/Mailbox – Some User ($484efb89)/0/Inbox/곯가가가걍걝걌곌겷걢곒갑겛개가검걟곔걙곾간곷갦가/at=겅걋각가:somefile.txt

    Characters that get encoded if they are in the store or folder display name

    Here is the table that shows which characters we encode:

        %    ->    %25, 
        /    ->    %2F 
        \    ->    %5C 
        *    ->    %2A 
        ?    ->    %3F 

    Algorithm to calculate the store hash

    Note that if a store has PR_MAPPING_SIGNATURE in the global profile section then that’s what we will hash instead of the store entry id. For all other stores we will hash the Entry ID.

    DWORD ComputeStoreHash(ULONG cbStoreEID, LPENTRYID pbStoreEID, LPCWSTR pwzFileName)
    {
        DWORD  dwHash = 0;
        ULONG  cdw    = 0;
        DWORD* pdw    = NULL;
        ULONG  cb     = 0;
        BYTE*  pb     = NULL;
        ULONG  i      = 0;
     
        // Get the Store Entry ID
        // pbStoreEID is a pointer to the Entry ID
        // cbStoreEID is the size in bytes of the Entry ID
        pdw = (DWORD*)pbStoreEID;
        cdw = cbStoreEID / sizeof(DWORD);
     
        for (i = 0; i < cdw; i++)
        {
            dwHash = (dwHash << 5) + dwHash + *pdw++;
        }
     
        pb = (BYTE *)pdw;
        cb = cbStoreEID % sizeof(DWORD);
     
        for (i = 0; i < cb; i++)
        {
            dwHash = (dwHash << 5) + dwHash + *pb++;
        }
     
        // You may want to also include the store file name in the hash calculation
        // Get store FileName
        // pwzFileName is a NULL terminated string with the path and filename of the store
        if (pwzFileName)
        {
            while (*pwzFileName)
            {
                dwHash = (dwHash << 5) + dwHash + *pwzFileName++;
            }
        }
    
        // dwHash now contains the hash to be used. It should be written in hex when building the URL.
        return dwHash;
    }// ComputeStoreHash

    Algorithm to encode the Entry ID and the attachment ID

    The goal of this algorithm is to generate a compact representation of the Entry ID or attachment ID.

    const WORD kwBaseOffset = 0xAC00;  // Hangul char range (AC00-D7AF)
    LPWSTR EncodeID(ULONG cbEID, LPENTRYID rgbID)
    {
        ULONG   i = 0;
        LPWSTR  pwzDst = NULL;
        LPBYTE  pbSrc = NULL;
        LPWSTR  pwzIDEncoded = NULL;
    
        // rgbID is the item Entry ID or the attachment ID
        // cbID is the size in bytes of rgbID
    
        // Allocate memory for pwzIDEncoded
        pwzIDEncoded = new WCHAR[cbEID];
        if (!pwzIDEncoded) return NULL;
    
        for (i = 0, pbSrc = (LPBYTE)rgbID, pwzDst = pwzIDEncoded;
            i < cbEID;
            i++, pbSrc++, pwzDst++)
        {
            *pwzDst = (WCHAR) (*pbSrc + kwBaseOffset);
        }
    
        // Ensure NULL terminated
        *pwzDst = L'\0';
    
        // pwzIDEncoded now contains the entry ID encoded.
        return pwzIDEncoded;
    }// EncodeID

    New notification to notify the MAPI PH of the process pushing MAPI URLs to be indexed

    A new MAPI notification type has been introduced to facilitate shutdown scenarios for pusher stores. These stores will have to persist what has to be pushed since it may not be able to index everything before a shutdown occurs. When a store provider is a pusher it should send the following notification so that the MAPI PH knows which process it should watch for a given store. This way if the process is shut down or crashes the MAPI PH will immediately detect that and close (stop indexing) the store it opened.

    #define fnevIndexing        ((ULONG) 0x00010000) 
    
    /* Indexing notifications (used for FTE related communications) */ 
    /* Shares EXTENDED_NOTIFICATION to pass structures below,       */ 
    /* but NOTIFICATION type will be fnevIndexing                   */ 
    
    // Stores that are pusher enabled (PR_SUPPORT_MASK contains STORE_PUSHER_OK) 
    // are required to send notifications regarding the process that is pushing. 
    #define INDEXING_SEARCH_OWNER        ((ULONG) 0x00000001) 
    
    typedef struct _INDEX_SEARCH_PUSHER_PROCESS 
    { 
        DWORD dwPID; /* PID for process pushing */ 
    } INDEX_SEARCH_PUSHER_PROCESS; 

    BLOB structure associated with each URL when indexing

    When pushing URLs to be indexed pusher stores should also create a blob with some information that will be used by the MAPI PH. This blob will be associated with each URL and will be sent when the URL is pushed to the indexer.

    The format of the blob is the following:

    DWORD  dwVersion
    DWORD  dwFlags
    ULONG  cbProfileName
    WCHAR  wszProfileName	
    ULONG  cbProviderItemID
    WCHAR  wszProviderItemID

    Note that these values have to be written to the blob in the order shown above. The provider item ID should only be sent for folders to prevent opening extra folders to get this information.

    Parameters

    dwVersion

    This is the version of the data being sent. Currently this value is 1.

    dwFlags

    Reserved for future use. Currently this should be 0.

    cbProfileName

    Size of the profile name in bytes. This information will be useful for the MAPI PH to know which profile to use when indexing the item.

    wszProfileName

    Null terminated Unicode string with the profile name.

    cbProviderItemID

    Size of the Provider Item ID in bytes

    wszProviderItemID

    Null terminated Unicode string with the provider item ID that uniquely identifies the item in the store.

  • SGriffin's MAPI Internals

    Outlook 2007 RTM Docs - Blocked Attachments

    Posted over 5 years ago
    by Stephen Griffin - MSFT
    • 4 Comments

    [This is now documented here: http://msdn.microsoft.com/en-us/library/bb820936.aspx]  

    (Now that Outlook 2007 is available I'm reposting some of the articles from the Outlook 2007 Beta Documentation series. Some of the articles are virtually unchanged, others are completely different to reflect the differences between Beta and RTM. This article is the updated version of Outlook 2007 Beta Documentation - Blocked Attachments.)

    Microsoft Outlook includes a feature that blocks attachments that are considered unsafe. The attachments which are blocked can vary from client to client depending on how Outlook is configured and on policies the administrator may have applied. See http://support.microsoft.com/kb/829982 for more information on how this is configured.

    Custom code can query to see if a particular attachment is considered blocked by Outlook using the IAttachmentSecurity interface. This interface exposes a function, IsAttachmentBlocked, which will analyze a file name and report if this attachment is considered blocked by Outlook and won’t be shown in the UI or indexed.

    Definition

    DEFINE_GUID(IID_IAttachmentSecurity,
    			0xB2533636,
    			0xC3F3, 0x416f, 0xBF, 0x04, 0xAE, 0xFE, 0x41, 0xAB, 0xAA, 0xE2);
    #define MAPI_IATTACHMENTSECURITY_METHODS(IPURE) \
    MAPIMETHOD(IsAttachmentBlocked) \
    		(LPCWSTR pwszFileName, BOOL *pfBlocked) IPURE; 
    
    DECLARE_MAPI_INTERFACE_(IAttachmentSecurity, IUnknown)
    {
        BEGIN_INTERFACE
        MAPI_IUNKNOWN_METHODS(PURE)
        MAPI_IATTACHMENTSECURITY_METHODS(PURE)
    };

    Usage

    This interface can be obtained by calling QueryInterface on the MAPI session object, requesting IID_IAttachmentSecurity. IsAttachmentBlocked will return true in pfBlocked if the attachment is considered blocked by Outlook and won’t be shown in the UI or indexed
    HRESULT IsAttachmentBlocked(LPMAPISESSION lpMAPISession, LPCWSTR pwszFileName, BOOL* pfBlocked)
    {
    	if (!lpMAPISession || !pwszFileName || !pfBlocked) return MAPI_E_INVALID_PARAMETER;
    
    	HRESULT hRes = S_OK;
    	IAttachmentSecurity* lpAttachSec = NULL;
    	BOOL bBlocked = false;
    
    	hRes = lpMAPISession->QueryInterface(IID_IAttachmentSecurity,(void**)&lpAttachSec);
    	if (SUCCEEDED(hRes) && lpAttachSec)
    	{
    		hRes = lpAttachSec->IsAttachmentBlocked(pwszFileName,&bBlocked);
    	}
    	if (lpAttachSec) lpAttachSec->Release();
    
    	*pfBlocked = bBlocked;
    	return hRes;
    }// IsAttachmentBlocked
Page 1 of 1 (6 items)
  • © 2012 Microsoft Corporation.
  • Terms of Use
  • Trademarks
  • Privacy Statement
  • Report Abuse
  • 5.6.402.223