Public Folder Admin Permissions Versus Client Permissions

Most Exchange administrators have noticed at one time or another that there are folders they can see and access through admin tools such as Exchange System Manager or PFDAVAdmin, but they can’t see or access those same folders through Outlook or OWA. I see a lot of confusion over this issue, so I want to explain a bit about how this works.

Each public folder has two sets of permissions – client permissions and admin permissions. These are stored in two separate properties on the folder. Let’s start by taking a look at these two different ACLs.

Client Permissions

When you’re thinking about public folder permissions, you’re usually thinking about client permissions. Client permissions are the ones you see when you get properties on a folder in Outlook, or when you use the Get-PublicFolderClientPermission cmdlet, or when you look at Folder Permissions in the ExFolders or PFDAVAdmin tool. Here are some screenshots of looking at client permissions from different interfaces.

Client permissions in Exchange System Manager

Client permissions in Outlook 2007

Client permissions in PFDAVAdmin

Client permissions in Powershell

Since folders in the hierarchy have typically been created by many different users, the client permissions are often different on each folder. The creator of the folder will be the Owner, and will often change the other rights on the folder as well, so there’s no telling what the client permissions will look like throughout the hierarchy.

Admin Permissions

Each public folder has a separate ACL that contains admin permissions. Admin permissions can only be seen through admin tools such as ESM or the Get-PublicFolderAdministrativePermission cmdlet. Here are some screenshots of looking at admin permissions.

Admin permissions in ESM

Admin permissions in Powershell

Unlike client permissions, admin permissions are typically the same on every folder in the hierarchy. While it’s possible to change the admin permissions on individual folders, that’s a very rare scenario. This means that in most environments, Exchange admins do have admin permissions to every folder in the public folder hierarchy.

Am I using admin or client permissions?

When you access a public folder, we only honor one ACL or the other – either the client OR the admin permissions, but not both! The ACL we use to determine your access to a folder is determined entirely by the tool you are using to access it.

• If you are using Outlook to access a public folder, we only look at the client permissions.
• If you are using Outlook Web Access to access a public folder, we only look at the client permissions.
• If you are using Exchange System Manager to access a public folder, we only look at the admin permissions.
• If you are using the Exchange Powershell public folder cmdlets or the Exchange 2007 public folder management GUI, we only look at the admin permissions.
• If you are using PFDAVAdmin or ExFolders to access a public folder, we only look at the admin permissions.

This means that while an administrator can see and access all the public folders through an admin tool, he does not have the same rights when using a client such as Outlook. The behavior is different between the two types of programs, because we only look at one ACL or the other.

This is actually controlled by the tool or client you are using. Any program has the option of asserting admin rights when connecting to the public store, but it is typically hard-coded and the user does not get a choice. The client programs never assert admin rights, while the admin programs always do. If you’re an admin using an admin tool, then you get to use the admin ACL instead of the client ACL to access the public folders through that tool, because the tool asserted admin rights when it connected to the public store.

One way to see this is to use the MFCMAPI tool. After logging on, if you go to the MDB menu and choose Open Public Store, you’ll see the following dialog box:

 

This shows a list of optional flags you can pass when opening the public store. Notice the very first one: 0x00000001 OPENSTORE_USE_ADMIN_PRIVILEGE. When a program passes this flag while opening the public store, it’s saying, “I’m an admin so let me use the admin permissions instead of the client permissions.” The store checks to see if the user has Exchange admin rights, and if so, he gets to use the admin ACL. MFCMAPI is the only tool I’m aware of that actually lets you choose whether to use the client or admin ACL by letting you modify the flags passed when opening the public store.

If you were writing your own tool, such as a migration tool that needs to access all the public folder content, then this is exactly what you would want to do – pass the OPENSTORE_USE_ADMIN_PRIVILEGE flag when opening the public folder store. If you assert admin rights when opening the store, then your tool automatically gets access to all the public folders (assuming it’s being run by an Exchange admin), and you don’t have to worry about the different client permissions on all the folders.

If you do need to access all public folders from a program that uses client permissions, you’ll need to use an admin tool to grant client permissions to the desired user on all the folders. This is easily accomplished using ESM, PFDAVAdmin, ExFolders, AddUsersToPFRecursive.ps1, etc.

Comments

• Anonymous
  January 01, 2003
  Yes, that's what the very top screenshot shows. That's what you see if you click Client Permissions on the PF properties in ESM.

• Anonymous
  May 16, 2012
  Excellent. Simple and to the point.

• Anonymous
  November 21, 2013
  excellent

• Anonymous
  January 26, 2015
  Hello Bill,
  
  Is their a way to get the client permissions tab for the Public folders within the ESM itself?