This content comes from a chapter removed from my book Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk (including a Kindle edition). The first part of the chapter is available in this post and the second here. This post completes the chapter on public folders.

– Tony

Public folder permissions are divided into client permissions, which allow clients to access the public folder and work with its contents, and administrative permissions, which manage the users who have administrative rights over the folder. Public folder permissions can only be manipulated through EMS or Outlook.

Client permissions

When you create a new public folder, a default set of client permissions is applied. You can see these permissions with the Get-PublicFolderClientPermission cmdlet:

Get-PublicFolderClientPermission –Identity '\Departments\Finance\Annual Budgets'

Identity     : \Departments\finance\annual budgets
User         : Default
AccessRights : {Author}
Identity     : \Departments\finance\annual budgets
User         : contoso.com/Exchange Users/Exchange Administrator
AccessRights : {Owner}
Identity     : \Departments\finance\annual budgets
User         : Anonymous
AccessRights : {CreateItems}

The first permission means that Exchange has assigned all users the Author permission. This means that all users can post new items to the public folder. Users have read access too, so they can copy items from the folder, including from the folder into a folder in their mailbox. They can also move items that they create from one public folder to another, or back into their mailbox. Authors are able to edit items that they create, but only with clients that support this capability. OWA doesn’t, but Outlook does.

The second permission tells us that the user called “Exchange Administrator” is the owner of the folder. The user that creates a folder automatically assumes this right and has total control over the folder, including the ability to delete it if they so desire.

The third permission allows anonymous users to create items in the folder. You have to set this permission on a public folder to allow non-authenticated users to email items to the folder. If you don’t expect this to happen (and haven’t mail-enabled the folder), you can remove the permission with the Remove-PublicFolderClientPermission cmdlet. For example:

Remove-PublicFolderClientPermission –Identity '\Departments\Finance\Annual Budgets' –User Anonymous –AccessRights 'CreateItems'-Server ExServer1

Client permissions are broken down into roles and individual client access rights. A role spans one or more client access rights and is therefore a convenient way to assign multiple client access rights in one operation. In the examples that we have discussed to date, CreateItems is a client access right that explicitly allows a client to create items in a public folder. On the other hand, Owner and Author are roles that both include the CreateItems client access right. Table 1 lists all of the available client access rights and the roles to which they are assigned.

Table 1 Public folder client access rights

Public folder client permissions are updated with the Add-PublicFolderClientPermission cmdlet. For example:

Add-PublicFolderClientPermission –Identity '\Departments\Finance\Annual Budgets' –User Redmond
–AccessRights 'Owner' –Server ExServer1

We reverse the process to remove client permissions on a public folder and use the Remove-PublicFolderClientPermission cmdlet.

Remove-PublicFolderClientPermission –Identity '\Departments\Finance\Annual Budgets' –User Redmond
–AccessRights 'Owner' –Confirm:$False

While you can cheerfully amend client permissions on a public folder, matters often are not straightforward because public folders operate in a hierarchy where child folders inherit the permissions of their parent. You might amend the permission on one folder and omit to make the same change on another and expose information to unwanted access. The code to amend client permissions on a folder and be sure that all of the permissions are respected by child folders is complicated. For this reason, Microsoft provides two scripts with Exchange to allow you to replace a user with another user for a folder and to replace a user’s permission with another set of permissions on a folder. Both scripts perform recursive updates to ensure that the same changes are applied to child folders. The scripts are:

• ReplaceUserWithUserOnPFRecursive.Ps1 (replace complete user with another)
• ReplaceUserPermissionOnPFRecursive.Ps1 (replace permissions for a user)

The Public Folder Settings Wizard provided in Exchange 2010 SP1 (Figure 1) makes the process even easier. You can opt to set permissions on a single public folder or on a folder and all its children. In addition, you can assign permissions to multiple users at one time and select a different set of permissions to assign to each user.

Figure 1: Assigning permissions to a public folder with the Exchange 2010 SP1 wizard

Like mailboxes and other mail-enabled objects, you can assign permission for a user to send email on behalf of a mail-enabled public folder. This requires you to grant the Send As Active Directory right to a user. Once the right is granted, the user can select the public folder from the GAL and address a message from them as shown in Figure 2.

Figure 2: Sending a message on behalf of a public folder

Replies sent in response to the message are delivered to the public folder. The Add-AdPermission cmdlet is used to grant the Send-As right, as shown in this example:

Add-AdPermission –ExtendedRights 'Send-As' –Identity 'CN=Annual Budgets,CN=Microsoft Exchange System Objects,dc=contoso,dc=com' –User 'Redmond, Tony'

Administrative permissions

Public folder administrative permissions are assigned through RBAC roles or specifically to the owner of a folder. We can use the Get-PublicFolderAdministrativePermission cmdlet to view the administrative permissions on a folder. If we do this for the folder for which we’ve been playing with client permissions, we see:

Get-PublicFolderAdministrativePermission –Identity '\Departments\Finance\Annual Budgets' |Select User, AccessRights | Format-Table -AutoSize

User                               AccessRights
----                               ------------
CONTOSO\Organization Management    {ViewInformationStore}
CONTOSO\Public Folder Management   {ViewInformationStore}
CONTOSO\Organization Management    {AdministerInformationStore}
CONTOSO\Public Folder Management   {AdministerInformationStore}
CONTOSO\Organization Management    {ModifyPublicFolderACL}
CONTOSO\Public Folder Management   {ModifyPublicFolderACL}
CONTOSO\Organization Management    {ModifyPublicFolderQuotas}
CONTOSO\Public Folder Management   {ModifyPublicFolderQuotas}
CONTOSO\Organization Management    {ModifyPublicFolderAdminACL}
CONTOSO\Public Folder Management   {ModifyPublicFolderAdminACL}
CONTOSO\Organization Management    {ModifyPublicFolderExpiry}
CONTOSO\Public Folder Management   {ModifyPublicFolderExpiry}
CONTOSO\Organization Management    {ModifyPublicFolderReplicaList}
CONTOSO\Public Folder Management   {ModifyPublicFolderReplicaList}
CONTOSO\Organization Management    {ModifyPublicFolderDeletedItemRetention}
CONTOSO\Public Folder Management   {ModifyPublicFolderDeletedItemRetention}
CONTOSO\Exchange Servers           {AllExtendedRights}
CONTOSO\E14Admin                   {AllExtendedRights}
CONTOSO\Organization Management    {AllExtendedRights}
CONTOSO\Exchange Trusted Subsystem {AllExtendedRights}
CONTOSO\Enterprise Admins          {AllExtendedRights}
CONTOSO\Domain Admins              {AllExtendedRights}

This data means:

• Members of the Organization Management and Public Folder Management RBAC role groups have the rights to manage the properties of the public folder and perform tasks such as modifying the client permissions list, the quota for the folder, the administrative permissions, the expiry settings for the folder and its content, add or remove replicas from the folder replica list, and change the deleted items retention setting for the folder. To discover the users who have these rights through their membership of a role group, type:

Get-RoleGroupMember –Identity 'Public Folder Management'

• Specific permissions are assigned to individual accounts or groups. These rights allow the accounts or groups to work with the folder at the specified level. AllExtendedRights is specified here, meaning that all administrative permissions are available, but you can allow or deny individual permissions as required. The folder owner is automatically included (E14Admin in this example) as are the members of the Enterprise Admins and Domain Admins group. You can also see that the Exchange Trusted Subsystem is included to allow Exchange to perform background maintenance on public folders. To check the owners assigned to a public folder, type:

Get-PublicFolderAdministrativePermission –Identity '\Departments\Finance\Annual Budgets' –Owner

The easiest way to assign public folder administrative permissions is to add users to the Public Folder Management role group. For example, to add user Smith to the Public Folder Management role group:

Add-RoleGroupMember –Identity 'Public Folder Management' –Member Smith

Likewise, the easiest way to remove administrative permissions is to remove users from the Public Folder Management group.

Remove-RoleGroupMember –Identity 'Public Folder Management' –Member Smith

Membership of the public folder management role group allows a user to manage the entire public folder hierarchy. You only need to resort to assigning specific administrative permissions if you want to allow someone to manage a sub-section of the hierarchy or anything from one folder to a complete set of folders and their children. In this scenario, the Add-PublicFolderAdministrativePermission and Remove-PublicFolderAdministrativePermission cmdlets provide the way to control permissions. You have to add or remove permissions; there is no way other way to update or change existing permissions.

For example, if we wanted to allow a user to have administrative permissions over the Finance folder, we’d use a command like this:

Add-PublicFolderAdministrativePermission –Identity '\Departments\Finance' –User 'Redmond' –AccessRights 'AllExtendedRights'

The permission is removed with:

Remove-PublicFolderAdministrativePermission –Identity '\Departments\Finance'
–User 'Ruth' –AccessRights 'AllExtendedRights' –Confirm:$False

MAPI clients like Outlook have been able to access public folders since the earliest version of Exchange and remain the most functional client in that you can set permissions for a folder, view the storage used for a folder, and so on. OWA has had a somewhat erratic history with public folders with missing features or even support for public folders completely non-existent, as happened in the RTM version of Exchange 2007. Public folders are supported by OWA 2010 and present much the same attractive interface as mailbox folders do (Figure 3). It’s important to understand that before OWA 2010 can connect to a public folder, a replica of that folder must exist on an Exchange 2010 mailbox server. OWA 2010 is not able to access public folders on Exchange 2003 or 2007 servers.

Figure 3: Accessing public folders with Outlook Web App

The biggest limitation is that public folders are presented in a separate window fromthe rest of OWA. This means that while you can post items directly into public folders, you cannot drag and drop items from mailbox folders into a public folder. The workaround is to go to the mailbox folder, select the item that you want to move, right-click, and then select the Move To Folder or Copy To Folder option followed by the target public folder (Figure 4). And of course you can always email items to public folders, provided that they are mail-enabled.

Figure 4: Moving an item into a public folder with Outlook Web App

Apart from not being able to drag and drop items or files into a public folder, the other minor irritant that users notice most often is the delay that can exist before new content is available across the different replicas. Remember, the default replication schedule updates replicas every 15 minutes, so it is possible that a user will have to wait up to 15 minutes before they see an item. The solution is to decrease the replication interval so that items are copied more quickly, if available bandwidth allows. I’ve also noticed that new folders don’t always show up quickly in the hierarchy despite immediate replication and that I have to refresh the folders to get them to show up. This isn’t a big problem and it’s certainly one that is very livable with, given that not many new public folders are created today.

Incoming connections from Outlook clients to mailboxes are served by the RPC Client Access layer running on a CAS server and not by the server that hosts the mailbox. However, if an Outlook client needs to connect to a public folder, they continue to connect directly to the nearest mailbox server that hosts a replica of the public folder. The logic in excluding public folders from the new database replication mechanism is not because the data held in public folders is any less important than mailboxes. Instead, it’s because public folders have had their own multi-replica replication model since the first version of Exchange. This replication works well and there’s no real need to replace it at this point. However, if you want to provide high availability for public folders, you have to configure multiple replicas and ensure that more than one replica exists in each site. Microsoft’s view is probably fair as they avoided a great deal of engineering effort that might potentially have introduced some instability in Exchange 2010 by leaving public folder replication alone, but it does create an interesting split between two separate replication mechanisms in the product.

Public folders have their own form of replication that is item-based rather than using asynchronous log replication as in a DAG. Some commentators have asked why Microsoft did not change public folder replication to use log shipping. The answer varies depending on whether it is delivered by an engineering or marketing spokesperson or if you care to read between the lines, but basically you can interpret Microsoft’s position as follows:

• Public folders have had multi-master replication since Exchange 4.0; replication today essentially works in the same way that it worked in 1996, so given that this mechanism has stood the test of time, why would you change it?
• Changing the replication mechanism would introduce unnecessary complication, costs, and risks into the engineering schedule for an area that is non-core for Exchange.
• The existing replication mechanism works smoothly between Exchange servers of different versions. Changing the mechanism would require some method of reconciling the differences between the “old” and the “new” versions, including the issue of dealing with multiple changes applied to a single item from different public folder servers.

The replication mechanism for public folders is unlikely to change anytime soon. Bearing this point in mind, you can upgrade the advice about deploying public folders in a fault-tolerant manner that has been used since 1996 as follows:

• Whenever possible, deploy separate servers for mailbox and public folders.
• Deploy at least two public folder servers per site and replicate important folders to allservers to ensure that clients can access a local replica even when one server is unavailable.
• Analyze public folder usage on a regular basis and do not allow folders to proliferate without good reason; eliminate unused folders as soon as you can to restrict replication traffic and remove network load. Many other platforms (such as SharePoint) provide superior features for requirements such as shared document management, so always consider the alternatives  before you create a new public folder.

Over the years, Microsoft has released a number of tools to help administrators manage public folders. The tools were originally developed and used by Microsoft Support to help them debug problems with public folder permissions, replication, and so on. PFAdmin for Exchange 2003 was followed by PFDAVAdmin in Exchange 2007. However, the deprecation of WebDAV means that the PFDAVAdmin tool does not work with Exchange 2010 and so it has been replaced with the ExFolders tool for Exchange 2010. ExFolders is essentially a port of PFDAVAdmin, updated and improved to deal with the Exchange 2010 database structures.

ExFolders doesn’t come with a very sophisticated installation procedure. You download it from the Microsoft website and place the executable in the Exchange binaries directory and launch the program. You then connect to either a mailbox or a public folder database and a domain controller. The domain controller provides access to the Exchange configuration data. After that, it’s a matter of navigating to the point in the folder or mailbox hierarchy that you’re interested in. ExFolders does a good job of revealing information in a more user-friendly and graphical manner than EMS. Figure 5 shows how to list permissions on a public folder. It’s the same data as you see with the Get-PublicFolderClientPermission cmdlet, but it’s a lot easier to view and understand.

Figure 5: Viewing public folder permissions with ExFolders

Unlike Exchange’s Public Folder management console, ExFolders is able to list some information about items that are in a public folder (Figure 6). Even better, ExFolders is able to view deleted folders and restore them. Sometimes the restore isn’t possible, but when it is, it’s a real life-line to rescue the embarassment caused by a mistaken folder deletion.

Figure 6: Listing items in a public folder with ExFolders

In addition to public folder databases, ExFolders can open and explore mailbox databases. Many interesting items can be discovered in mailboxes, such as the structure of the mailbox and the many hidden items that are stored in the mailbox root to be used for Exchange internal processing. Figure 7 is a good example. You can see the two move reports that Exchange holds for a mailbox. You can also see the dumpster folder structure (under Recoverable Items), the folders used for Reminders and Views, and the client-visible folder structure under Top Of Information Store.

Figure 7: Viewing mailbox data with ExFolders

Even if you’re not interested in public folders, ExFolders is a very valuable tool for an Exchange administrator. It doesn’t come with formal support and it doesn’t work so well from time to time, but these small deficiencies are absolutely unimportant in the context of the value that the program delivers.

The Exchange development group includes a set of scripts in the installation kitthat they have developed to help with public folder management. When you install a mailbox server, the scripts are placed into the \Scripts directory under the Exchange \V14 root. The scripts demonstrate that some public folder management tasks are complex, especially those that deal with deep folder hierarchies. All of the work done by the scripts is accomplished by the cmdlets that we have discussed in this section and, while they might not solve all the problems that you encounter, the scripts can be customized to extend their functionality or to address some important but esoteric detail of your deployment.

Table 2 offers a brief description of the scripts provided with Exchange and their use.See the Exchange help file for further information on the input parameters or simply browse through the script code to see how it works.) The Exchange scripts directory should be in the path that Windows PowerShell uses to locate scripts, so you should be able to type in the name of the script to execute it. If not, position yourself in the directory where the scripts are located and prefix the name of the script that you want to execute with ‘.\’ or provide the full path to the script. For example:

C:> .\AggregatePFData.ps1

Or

C:> 'Program Files\Microsoft\Exchange Server\V14\Scripts\AggregatePFData.ps1'

Table 2 Public folder administration scripts

No one has yet developed a magical silver bullet to migrate the data and applications that companies have accumulated in public folders since 1996. Every deployment uses public folders differently and every company needs to develop their own plan.

The first challenge is to understand the inventory of public folders that exist and then identify the folders that are actually in use. You can use the AggregatePFData script, or indeed the Get-PublicFolderStatistics cmdlet, to create a report about the current set of public folders. Such a report is a good first step to understand the folders that exist and the ones that are actually in use. However, you’ll still be missing some data such as why the public folder was created, who created the folder and who manages it now, whether the folder is associated with an application and what functionality is represented by the application, or anything about the business value of the data held in the folder. These questions have to be answered through patient and detailed investigation.

As part of the inventory process, it is helpful to categorize public folders according to their use as this may determine whether it is worthwhile to move the data and what suitable platforms exist as a migration target. Common uses for public folders include:

• Repositories for forms-based applications, sometimes workflow in nature. These applications are much more common in companies who deployed the first few versions of Exchange (pre-Exchange 2000) because of the heavy emphasis that Microsoft then placed on electronic forms linked to public folders.
• Project document repositories. These folders store an eclectic set of items in varying formats from mail messages to Word documents to Excel worksheets. Users post items to the folders on an on-demand ad hoc basis by including the folder in project distribution groups, creating new post items in the folder, or dragging and dropping from Outlook or Windows Explorer.
• Archives for discussion groups. Exchange has never offered list server functionality, but people created their own basic implementation by using distribution groups as the list and a public folder (automatically copied on every post by including the SMTP address of the folder in the list) as the list archive.

One option is to ignore the data in public folders on the basis that it is old and of no relevance to current company operations. This might be true, but it might also be true that some data is required to comply with regulatory or legal requirements, so you need to know if any data falls into this category. The only cost for this option is some storage to maintain the public folder databases.

Another option is “degrade in place.” This means that you leave the data and applications in place until users stop accessing them. Perhaps you run a report every month to identify folders that have not been accessed in the last 180 days and then export the contents of these folders to a PST and write the PST to DVD before you remove the folder and all its replicas.

The third option is to seek another platform for the public folder and move all content and applications there to allow you to decommission public folders and remove them completely from Exchange. While Microsoft doesn’t provide any public folder migration utilities, you can find them such as Quest Software’s Public Folder Migrator for SharePoint. As the name implies, this utility moves content from public folders to SharePoint team sites or portals. Over the last few years, SharePoint has become the most popular platform considered for public folder migration, partly because tools have slowly become available to enable the move, partly because the Microsoft Exchange and SharePoint engineering groups have given hints that they prefer this option. See this post for some evidence on this point. It’s also true that migrating to another Microsoft solution often aligns well with the IT strategy of companies.

If you have developed code for use with public folders, you are going to have to redevelop the application for use on a new platform. While it’s relatively easy to move data to a new platform, it’s much more difficult to handle the accompanying logic embedded in code that was probably written several years ago. No tools exist today to address this need.

The bottom line is that public folders are well past their sell-by date as an application platform. There is no good reason to continue to invest in public folders and you need a plan to move off them before the curtain comes crashing down. Chose a new platform and invest your time into tailoring it for your purpose. It will be time that generates more rewards than trying to extract the last possible gasps out of public folders.