Why Can't I Open The Mailbox?

 

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