Working with Public Folder and Mailbox Permissions
Letztes Änderungsdatum des Themas: 2006-05-25
By Nino Bilic.
This article contains information on how permissions are inherited on Microsoft® Exchange Server stores as well as good information on public folder permissions and minimum permissions required for mailbox and public stores to work. It is a compellation of material taken from the sources listed in the "For More Information" section below.
- Using Exchange Administrative Roles with Exchange Store Components
- Understanding the Types of Permissions That Control Access to Mailboxes and Public Folders
- Using Mailbox Permissions
- Using Public Folder Permissions
- Maintaining the Minimum Permissions Required for Mailbox Stores and Public Folder Stores
- For More Information
This section explains what access the various Exchange Server administrative roles (Exchange Full Administrator, Exchange Administrator, and Exchange View Only Administrator) provide to mailbox stores, public folder stores, and public folder trees.
In order to perform most of the tasks described in this part of the article, you must have at least Exchange Administrator permissions on the administrative group where you are working.
Use the information in the following table and picture to identify what permissions are involved, and how the Exchange store objects inherit these permissions. This will help you to recognize situations where you may need a different administrative role or different permissions.
The following table summarizes the permissions for the three Exchange administrative roles on Exchange store objects.
Exchange Full Administrator
Additional permissions in Active Directory to allow you to work with deleted items and offline address lists
All except Change Permissions
Additional permissions in Active Directory to allow you to work with offline address lists
Exchange View Only Administrator
View Information Store Status
The following illustration shows the direction of inheritance of permissions for Exchange Full Administrators, Exchange Administrators, or Exchange View Only Administrators.
As shown in this diagram, objects in the Exchange store inherit permissions from their administrative group, with the following exceptions:
Delegating Exchange administrative roles on an administrative group gives administrators in those roles limited permissions on mailboxes—enough to create or delete mailboxes, and set options such as storage limits.
A public folder inherits some administrative permissions from the public folder tree where it resides. It does not inherit permissions from the public folder store.
Administrative rights on a public folder include many folder-specific permissions that are not available on the public folder tree. For example, although an Exchange Server Administrator cannot modify the permissions on a public folder tree, the administrator can modify permissions on a public folder in that tree.
|For an administrator to apply a system policy to a store, the administrator must have the appropriate permissions on both the System Policies container and on the target store. If you are using a distributed administration model with multiple administrative groups that have separate administrators, each administrator will be able to interact only with the stores in that administrator's own administrative group.|
|Public folder trees and their public folders can only be administered in the administrative group where they were created, even though you can replicate folders in the tree to multiple administrative groups. If you are using a distributed administration model with multiple administrative groups that have separate administrators, each administrator can work with the public folder stores in that administrator's own administrative group, but may not have access to the public folders that those stores support.|
The following section explain how the permissions on store contents, mailboxes, public folders, and the messages they store, are much more complex than permissions used elsewhere in Exchange Server, and provide basic information about how to use these permissions.
|A detailed explanation of how these permissions work is beyond the scope of this article. For a full explanation of how store permissions work, see "Working with Store Permissions in Exchange 2000 and 2003."|
If you are doing any troubleshooting with store permissions, or if you need to modify permissions in ways other than the delegation methods described later in this article, it is strongly recommended that you study "Working with Store Permissions in Exchange 2000 and 2003" first.
The access control lists (ACLs) on public folders, mailboxes, and the messages that they contain use Microsoft Windows® 2000 Server permissions to control access (with a few additional permissions that are specific to Exchange Server). This is a change from Microsoft Exchange Server 5.5, in which the ACLs used MAPI permissions. Exchange Server 2003 substitutes MAPI permissions for Windows 2000 Server permissions in the following circumstances:
When communicating with MAPI-based client applications, such as Microsoft Outlook. In this case, Exchange Server converts the permissions to MAPI permissions when displaying them to the user. If the user modifies the permissions, Exchange Server converts them back to Windows 2000 Server permissions to save them.
When replicating data to Exchange Server 5.5 servers in a deployment that contains coexisting servers that run Exchange Server 5.5 and servers that run Exchange Server 2003. Because Exchange Server 5.5 servers only use MAPI permissions, Exchange Server 2003 replicates permissions to them in the MAPI format. When the permissions replicate back to Exchange Server 2003 servers, Exchange Server 2003 converts them to the Windows 2000 Server format before saving them.
|Both of these circumstances apply to mailboxes and to public folders in the Public Folders tree (and all of the folders and messages contained in it). Folders and messages in general-purpose public folder trees cannot be accessed by MAPI-based clients and are not replicated to Exchange Server 5.5 servers. Therefore, Exchange Server always uses Windows 2000 Server permissions with these folders and messages.|
Exchange Server handles all conversions between Windows 2000 Server permissions and MAPI permissions automatically. However, as an administrator, be aware that when you use Exchange System Manager to set permissions, you may need to work with either Windows 2000 Server permissions or MAPI permissions, depending on the type of object you are securing.
When you create a new mailbox, Exchange Server uses information from the mailbox store to create the default permissions for the new mailbox. The default folders in the new mailbox inherit permissions from the mailbox itself. Users can modify the permissions on folders in their mailbox using Outlook. Outlook uses MAPI permissions, which Exchange Server automatically converts to Windows 2000 Server permissions when it is storing the changes.
Although you can use Exchange System Manager to delete or move mailboxes, you cannot use it to access mailbox content or mailbox-related attributes of the user. Use Active Directory Users and Computers (Dsa.msc) to perform administrative tasks on the Exchange-related attributes of user objects. In addition, you must use Active Directory Users and Computers to give users permission to access the mailbox itself, as discussed in the next section.
For administration and troubleshooting purposes, there are times when you need to access a user's mailbox. There also may be occasions where it is appropriate for a second user to have access to a mailbox. This second user is referred to as a mailbox delegate.
You can give users delegate permissions for a mailbox by modifying the Microsoft Active Directory® directory service user account that is associated with the mailbox. Use Active Directory Users and Computers for this task. You can give different levels of access to the mailbox:
If you give the second user the access level of Full Mailbox Access, Exchange Server treats that user as the mailbox owner. The second user does not need any other permissions on folders in the mailbox.
If you give the second user an access level other than Full Mailbox Access, the original mailbox owner can use Outlook to set permissions for the second user on folders in the mailbox.
The following sections discuss how to use public folder permissions.
You can control access to public folders using the following types of permissions:
- Client permissions These settings control who can use client applications to access folders and messages. By default, all users have permissions to read and write content in the public folder. You can change permissions for all users or create different permissions for specific users. The default client permissions do not include the Exchange administrative roles (Exchange Full Administrators, Exchange Administrators, or Exchange View Only Administrators).
Depending on the type of public folder that you are working with, you may see different forms of the client permissions.
Folders in the Public Folders tree use MAPI permissions.
Folders in general-purpose public folder trees use Windows 2000 Server permissions.
- Folders in the Public Folders tree use MAPI permissions.
- Directory rights These settings are normal Active Directory permissions, and control who can change the e-mail–related attributes of a mail-enabled public folder. Exchange stores these attributes in Active Directory, in the public folder's directory object in the Microsoft Exchange System Objects container. The default directory permissions include extensive permissions for the domain local Administrators group. Normally, any user that you have assigned to one of the Exchange administrative roles is a member of this group.
- Administrative rights These settings control who can use Exchange System Manager (or a custom administration program) to change the replication, limits, and other settings for a public folder. Some of these permissions are inherited from the public folder store and include permissions for the Exchange administrative roles. These permissions are Windows 2000 Server permissions, although they reside only in the public folder store.
If you are working with a public folder tree that has multiple levels of public folders, you can modify client permissions or administrative rights for a single folder, and you can use the Propagate Settings command to propagate the changes to all subfolders of that folder. To propagate client permissions, use Propagate Settings with the Folder rights option. To propagate administrative rights, use Propagate Settings with the Administrative rights option.
When you use Exchange System Manager to view client permissions for a public folder, the information that you see can depend on what type of folder tree you are working with. You also have access to different views of the same information. The procedures in this section provide information about how to use and how not to use the different views.To view permissions that control client access to a public folder
In Exchange System Manager, right-click the folder that you want to change, and then click Properties.
In the Properties dialog box, click the Permissions tab, and then click Client permissions.
After you click Client permissions, one of two different dialog boxes appears, depending on the type of public folder tree with which you are working.
If you are working with a folder in the Public Folders tree, you see a dialog box that contains MAPI permissions and roles.
If you are working with a folder in a general-purpose public folder tree, you see a dialog box that contains Windows 2000 Server permissions, users, and groups.
You can also use Exchange System Manager to view the Windows 2000 version of the permissions on a folder in the Public Folders tree.
Vorsicht: Although you can view the Windows 2000 Server version of the Public Folders tree permissions, do not attempt to edit the permissions in this view. The Windows user interface that displays the permissions formats the ACL in such a way that Exchange Server will no longer be able to convert the permissions to their MAPI form. If this happens, you will no longer be able to use Outlook or the regular Exchange System Manager dialog boxes to edit the permissions.
In Exchange System Manager, right-click the folder whose permissions you want to view, and then click Properties.
From the Properties dialog box, click the Permissions tab, and then press and hold the CTRL key and click Client permissions.
The resultant dialog displays as below. Note that all of the permissions check boxes are cleared:
To see the actual permissions information, click Advanced. The resulting dialog box is shown below:
To view detailed permissions information, click a permissions entry and then click View/Edit.
Remember, do not use this dialog box to edit the permissions. As stated earlier, using this interface to modify permissions would save the changes in a form that Exchange Server could not convert to the MAPI format. The following screenshot shows an example of the detailed Windows 2000 Server permissions information you can view.
You can configure a mail-enabled public folder so that a user can send mail on the public folder's behalf. For example, if the folder serves as a shared storage location or workspace for a group of users, one user could send notifications to the group. A custom application could also perform such a function, if you created an account for it to use.To give a user the ability to send mail on behalf of a public folder
From Exchange System Manager, expand Folders, right-click the public folder for which you want to give a user the ability to send mail and click Properties.
Click Exchange General, and then click Delivery Options.
Click Add to specify a user.
You may need to make additional modifications if the following conditions apply:
The user's mailbox resides in a domain that is different from the public folder's domain.
The user's mailbox resides on a server that is located in a site that does not contain any domain controllers for the domain that hosts the public folder.
- The user's mailbox resides in a domain that is different from the public folder's domain.
Use one of the following additional steps:
Add the Exchange Domain Servers security group of the child domain with Read permissions to the ACL of the Microsoft Exchange System Objects container in the parent domain. This method is the recommended method for working around this problem.
Move one domain controller from the parent domain to the user's Exchange Server 2003 site.
- Add the Exchange Domain Servers security group of the child domain with Read permissions to the ACL of the Microsoft Exchange System Objects container in the parent domain. This method is the recommended method for working around this problem.
This section explains the minimum permissions that are required for mailbox stores and public folder stores to function correctly.
If you modify the default client permissions and roles on a mail-enabled public folder, make sure you maintain the Contributor role for the Anonymous account. Otherwise, mail sent to the public folder will be returned as undeliverable. When the public folder receives e-mail from a user who has no permissions on the folder, it treats the mail as a message posted using the Anonymous account.
|This is a change from Exchange Server 5.5, where the default role of the Anonymous account was None.|
If you modify the default permissions on Exchange Server 2003 mailbox stores and public folder stores, make sure you maintain the following minimum permissions:
- Administrators group Full Control
- Authenticated Users group Read and Execute, List Folder Contents, and Read
- Creator Owner None
- Server Operators group Modify, Read and Execute, List Folder Contents, Read, and Write
- System account Full Control
You may experience difficulties in mounting the mailbox stores or public folder stores if you do not maintain these permissions for these groups and accounts. The following error messages and events indicate that the accounts and groups in the preceding list do not have the correct permissions:
An internal processing error has occurred. Try restarting Exchange System Manager or the Microsoft Exchange Information Store service, or both.
MAPI or an unspecified service provider. ID no: 00000476-0000-00000000.
Information Store (2520) An attempt to determine the minimum I/O block size for the volume "[drive:\]" containing "[drive:\]Exchsrvr\Mdbdata\" failed with system error 5 (0x00000005): "Access is denied." The operation will fail with error -1032 (0xfffffbf8).
Error 0xfffffbf8 starting Storage Group [dn of storage group] on the Microsoft Exchange Information Store.
The MAPI call 'OpenMsgStore' failed with the following error: The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance. The MAPI provider failed. Microsoft Exchange Server Information Store ID no: 8004011d-0526-00000000.
You may also encounter problems when mounting public folder stores if you have cleared the Allow inheritable permissions from parent to propagate to this object option for the public folder hierarchy. The following error messages indicate that you have cleared this option:
The store could not be mounted because the Active Directory information was not replicated yet.
The Microsoft Exchange Information Store service could not find the specified object. ID no: c1041722.
In Exchange System Manager, right-click the Folder container, select the public folder tree, and then click Properties.
In the Properties dialog box, click the Security tab, click Advanced, and then select Allow inheritable permissions from parent to propagate to this object.
Wait for Active Directory to replicate the change to all of the domain controllers.
Right-click the public folder store and click Mount Store.
For more information, see the following Exchange Server resources, Web sites, and Microsoft Knowledge Base articles: