Exchange Server

Exchange Server

Exchange Server: Understanding Public Folder Permissions

Public folders, introduced in the first version of Microsoft Exchange, are designed for shared access and provide an easy and effective way to collect, organize, and share information with other people in your workgroup or organization. Public folders are hierarchically organized, stored in dedicated databases, and can be replicated between servers running Exchange.

Public folders aren't designed for the following purposes:

• Archiving data Public folders aren't designed for archiving data. Users who have mailbox limits sometimes use public folders instead of their personal folders (.pst) files to archive data. This practice isn't recommended because it affects storage on public folder servers and undermines the goal of mailbox limits.
• Document sharing and collaboration Public folders aren't designed for document sharing and collaboration. Public folders don't provide versioning or other document management features, such as controlled check-in and check-out functionality, and automatic notifications of content changes.

Exchange Server public folder permissions are something you need to think about up front -- before you even start to create your public folder hierarchy. Otherwise, you could have a big mess on your hands.

Exchange Server public folders usually serve as a repository for information that needs to be accessible to everyone or a specific subset of users (such as a group of users collaborating on a project). Since Exchange public folders are hierarchical in nature, it is important to organize them based on what types of access users will need.

Understanding the Types of Permissions That Control Access to Mailboxes and Public Folders

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.

Understanding the Three Types of 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.
• 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.

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

To restore permissions inheritance

1. Right-click the public folder MAPI tree, and then click Properties.
2. In the Properties dialog box, click the Security tab, and then select the Allow inheritable permissions from parent to propagate to this object check box.

After you complete this procedure, wait for the Active Directory directory service to replicate the change to all of the domain controllers. After the change has been replicated, you can remount the store.

About the Author

Tatiana Tokarieva has an experience working with email recovery software, Exchange Server. Read more her articles about how to restore email.

Exchange Server 2010: Improvements to Unified Messaging in Exchange Server 2010