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:
- 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)
- Enumerates the user’s group membership
- Assesses the group membership against the ACLs on the Public Folder
- 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”).
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.
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 ???
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
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
Thank you very much for this article, very helpful!
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.
it’s really work instantly.Thanks for the solution.
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?
Thanks !
It works far better now I have permitted “Anonymous” & “default” to create new items …
Yours did the trick Mr. Mattson.
Thanks
Paul! Your thing did the trick! Thanks!
Pingback: Butsch.ch
Thanks Paul, just what I was looking for.
Thanks.
Solved my problem.
Regards
Christian
Hi Paul Mattson
Used your method, and it solved my problem,
Thank you
Mikkel
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!
I have same issue but had been working for some years. dismounted public store, repaired DB using trouble shooter, remounted and all ok now…
Thanks Paul Mattson,
your method worked for me as well.
“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.