In some scenarios a mailbox user sending emails to a mail-enabled Public Folder may receive an undeliverable message in reply.

The message contains the following error details:

#550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service
reported an error.  The following information should help identify the cause
of this error: "MapiExceptionNotAuthorized:16.18969:57080000..."

This error can occur under a variety of configurations relating to Public Folder client permissions.

External Senders

External senders will receive the error if the Public Folder does not permit “Anonymous” to create new items.

[PS] C:\>Get-PublicFolderClientPermission pftest

Identity                   User                       AccessRights
--------                   ----                       ------------
pftest                    Default                    {FolderVisible}
pftest                    mycompany.local/Users/A... {Owner}
pftest                    Anonymous                  {None}

To grant this access run the following command in the Exchange Management Shell.

[PS] C:\>Add-PublicFolderClientPermission pftest -User Anonymous -AccessRights CreateItems

Identity                   User                       AccessRights
--------                   ----                       ------------
pftest                    Anonymous                  {CreateItems}

Internal Senders

Internal senders are able to be authenticated by the Exchange server, and so are not treated as Anonymous. For internal senders the user must have at least Create Items permissions on the Public Folder. For general use Public Folders this can be granted as the “Default” permission.

To grant this access run the following command in the Exchange Management Shell.

[PS] C:\>Add-PublicFolderClientPermission pftest -user Default -AccessRights CreateItems

Identity                   User                       AccessRights
--------                   ----                       ------------
pftest                    Default                    {Contributor}

Internal Senders Alternate Scenario

Because internal senders are being authenticated by the Exchange server their group membership is taken into consideration. When the Exchange server receives a new item from an internal sender it takes the following basic steps:

  1. Maps the sender address to a user account object (this occurs even if the email was not sent by the user themselves, eg was sent via Telnet)
  2. Enumerates the user’s group membership
  3. Assesses the group membership against the ACLs on the Public Folder
  4. Permits or denies the mail item depending on the ACL

Because of this process the Exchange server must have Read access to the groups that the sender is a member of, including direct membership and indirect membership (eg by nested groups).

If the Exchange server cannot read a group object it will deny the mail item and the user will receive the undeliverable message with “MapiExceptionNotAuthorized”.  The reason for this is that it is designed to fail in a secure way (ie, “I can’t verify your access therefore I will deny you”), rather than an insecure way (ie “I can’t verify your access therefore I will permit you”).

Causes of MapiExceptionNotAuthorized Error Sending to Public Folders

With that in mind you would need to investigate all of the direct and indirect group membership for the user and try to locate a group object that does not have the Exchange Servers group with Read access in its ACL.  Most commonly this will occur when the group is in a Domain in the Forest that has not been prepped for Exchange, or is in an OU where permissions inheritance has been disabled.

Correcting the ACL on the group objects should resolve the undeliverable “MapiExceptionNotAuthorized” error in those cases.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Manas Dash

    Dear Paul,

    Why we called Outlook as MAPI client ? is there any MAPI protocol there ? I found only POP3 / IMAP not any MAPI. What is MAPI inside other than its definition as “message application programming interface”. Name is not sufficient to describe. How it integrate with outlook. what exactly we call outlook as mapi…i do not understand. Is there any communication protocol specific there in side outlook or what else ???

  2. Tejbhan Mishra

    You can run below command to check what permission external sender has Publicfolder
    get-mailpublicfolder PF@domain.com | Get-PublicFolder | Get-PublicFolderClientPermission -user Anonymous

    You can run below command to fix this issue.
    get-mailpublicfolder PF@domain.com | Get-PublicFolder | Add-PublicFolderClientPermission -User anonymous -AccessRights Createitems

  3. Mohamed sassi

    What if we have a tree :
    folder1 disabled Email
    folder2 enabled mail
    folder2 is a subfolder of folder1
    Do we have to make the same operation for the 2 folders?
    (default,anonymous)–>create items for the 2 folders ?
    Regards

  4. Mikael Hansen

    Thank you very much for this article, very helpful!

  5. a jr sysadmin

    Hi,

    I was having issues sending messages to a public folder and getting MapiExceptionNotAuthorized as the error.

    The first section fixed my problem.

    Went to the permissions for the public folder…
    Went to the anonymous object and gave it contributor permissions (create new items) and this fixed my issue. Thank you very much.

  6. Md. Atiqure Rahman

    it’s really work instantly.Thanks for the solution.

  7. Lee

    This didn’t work for me.

    Giving Anonymous or Default user the create item works but it is not what we want due to the strict permissions on the Public Folder.

    We have an Exchange 2010 resource forest and FIM provisions the distribution group into this forest. The source forest will retain all user accounts and access is via a “linked mailbox” It seems that the resource forest is not able to expand out the Distribution group (which has the create item permission).

    Seen this before?

  8. Christophe

    Thanks !
    It works far better now I have permitted “Anonymous” & “default” to create new items …

  9. Eric

    Yours did the trick Mr. Mattson.

    Thanks

  10. Michel

    Paul! Your thing did the trick! Thanks!

  11. Mark

    Thanks Paul, just what I was looking for.

  12. Christian Kjær

    Thanks.

    Solved my problem.

    Regards

    Christian

  13. Paul Mattson

    Thanks!

    The problem was resolved for us when I gave the anonymous user only the “Create items” permission on that public folder.

    I didn’t need to use powershell, Just:
    -RightClick the folder in Outlook
    -Click Permissions
    -Select Anonymous
    -Permission Level DropDown to “Contributor”
    -Unchecked “Folder visible”

    Works perfectly – Thanks again!

    1. carl

      I have same issue but had been working for some years. dismounted public store, repaired DB using trouble shooter, remounted and all ok now…

    2. JC

      Thanks Paul Mattson,

      your method worked for me as well.

  14. Kirk Lashbrook

    “If the Exchange server cannot read a group object it will deny the mail item… ”

    Very helpful info !

    I’ve had to troubleshoot this issue for internal users randomly not being able to send messages to a public folder. It’s not always the “CreateItems” permission on the PF that we would all check first.

Leave a Reply