Exchange 2010 Public Folders: Part 3

This content comes from a chapter removed from my book Microsoft Exchange Server 2010 Inside Out, also available at (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         : 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

Role CreateItems ReadItems CreateSubFolders FolderOwner FolderContact FolderVisible EditOwnItems EditAllItems DeleteOwnItems DeleteAllItems
Owner X X X X X X X X X X
PublishingEditor X X X X X X X X
Editor X X X X X X X
PublishingAuthor X X X X X X X
Author X X X X X
Non-EditingAuthor X X X
Reviewer X X
Contributor X X
None X

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

OWA and public folders

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.

Public folder connections and the CAS

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.

Fault-tolerant public folders

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.

The ExFolders utility

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.

Scripts provided for public folders

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


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

Table 2 Public folder administration scripts

Script Use
AddReplicaToPFRecursive.ps1 Adds a new server to the replica list for a folder and all its child folders. A public folder database must be present on the target server.
AggregatePFData.ps1 Aggregates public folder data for all replicas within an organization to provide a view of the amount of data held in the folders, the folder owners, and the last access time. The output for this script is best directed to a text or CSV file for later analysis. The version provided with Exchange 2010 RTM extracts data from just one public folder server while the version in Exchange 2010 SP1 extracts information from all folder replicas.
RemoveReplicaFromPFRecursive.ps1 Reverses the work of AddReplicaToPFRecursive.ps1 by removing the public folder database on a server from the replica list of a folder and all its child folders.
MoveAllReplicas.ps1 Replaces the public folder database hosted by a server with another in the replication list for all public folders. This script is typically used when you want to decommission a server that hosts a public folder database and you first need to move all the replicas from that server.
ReplaceReplicaOnPFRecursive.ps1 Replaces the public folder database on a server with another in the replica list for a folder and all its child folders.
AddUsersToPFRecursive.ps1 Add a user and specified permissions for that user to a folder and all its child folders.
ReplaceUserWithUserOnPFRecursive.ps1 Removes one user and replaces them with another in the permissions list for a folder and all its child folders.
ReplaceUserPermissionOnPFRecursive.ps1 Replaces the permissions for a specified user with new permissions for a folder and all its child folders.
RemoveUserFromPFRecursive.ps1 Removes a user from the permissions list for a folder and all is child folders.

Migrating public folder content

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.


About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Exchange, Exchange 2010 and tagged , , , . Bookmark the permalink.

49 Responses to Exchange 2010 Public Folders: Part 3

  1. erdem ustun says:

    I wrote this message your previous articles.part1 and part2.
    How to create public folders with powershell from csv file which contains publicfolder’s name,username(access,read rights)…etc.

    How can I Solve my problem. Can you help me about solving my problem.

    • Klaus says:

      Hi! Today I had to write a script copying Public Folder access rights from a template structure to another structure. Recursive. Folder names and structure are the same on both sides. You might get an idea from it how to solve your problem.
      Already have a valid credit card number, so email address or upload link would do.

  2. Sure I can help. Please provide me with a valid credit card number and I’ll be happy to bill you for the necessary time. Seriously, you can’t expect to ask a question like this on a blog and receive an answer that might take considerable work and research to produce. It would be better for you to do the work as a learning experience.

    I don’t have any problem answering questions – but I do have better things to do than to sit down and write code for others free of charge.

    – Tony

  3. erdem ustun says:

    what is your purpose of writing blog?
    this problem is none of your business you are right. it is my problem.I searched lots of documents,web sites,blog…etc but I could not. I tried to write some code as I have I saw your blog and think of you who is expert. I have mistaken of this imagine.
    Nothing is credit card or ….

    what is your purpose of writing blog? share? trade? show? satisfaction? identity?…..

  4. It’s a good question to ask – “why do you write a blog”? I suspect that the answer will be different from different bloggers. For me, it’s just a way to share information that I have as well as to provide commentary on topics that interest me.

    As to why I won’t write code on demand, well, I don’t think many authors – expert or not – will simply drop tools and churn out code as required by people who comment on their blog. Why should they anyway? You should view the exercise as a learning opportunity. There’s enough PowerShell sample code available on the Internet to use as the basis for a good start and there’s lots of books that explain how to create EMS scripts, so it’s not as if there is no information available.

    – Tony

  5. Good article Tony which I found valuable. Credit card …. ROFL

  6. Mike says:

    Very good article Tony. I however are strugling with permissions. I have migrated my Public folders from Keriomail to Exchange 2010 via a PST file. I have set all folders to have me as the owner and default and anonymous to none on all folders. I have done this using EMC, EMS and Exfolder. However all users still can view all folders and make changes to this. How can I fix this?



    • Hi Mike,

      I have no idea why you’d be running into this problem. Maybe you should take out a support case to Microsoft?


    • Klaus says:

      You cannot. It’s another bug. “Folder Visible” is not handled correctly in EMC and ExFolders. Both are “none”. You can use the shell though (we cannot since we’re having 300k+ folders, so 1 run would take ~1 week). You can see a difference between exporting “none” and “visible”. BTW – there’s another bug in ExFolders (a leak) that prevents larger environments from using it: After exporting 100k folders (Export Permissions), it’s consuming ~20GB of RAM and therefore crashing (out-of-memory because the server only has got 32GB and the store also needs a bit :).

  7. Martin says:

    Related to high availability for public folders, my understanding is, that even if a full replica is available on another PF server within the same site, it doesn’t seamlessly help Outlook clients if the default public folder database (that is configured with the mailbox database) is not available, but you must manually reconfigure the default public folder database for the user’s mailbox database so that Outlook can access public folder data. Looking back to e.g. Exchange 2003, we were able to configure an Exchange 2003 MSCS/failover cluster to support HA for PFs. Apart of cluster related complexity, this was a type of high availability for public folders which isn’t available any more with Exchange 2010. Any possible workarounds would be appreciated …

    • This problem has been discussed many times on the net (for example, I think the problem is that the switch to using the CAS as the MAPI endpoint might have interfered with the ability of Outlook to switch to another PF replica in the same site. The workaround is to run a quick PowerShell command to find the mailbox databases that use the PF database on the failed server and switch them to another PF database (one that hopefully has all the replicas). For example:

      Get-MailboxDatabase -Server PFFailedServer| Set-MailboxDatabase -PublicFolderDatabase PFDatabaseOnWorkingServer

      Sorry… comments on a postcard to Microsoft accompanied by a used $100 bill please.


      • Martin says:

        Hello Tony, thanks a lot for your quick reply. That in the end helped my to find the following article: . That kb article however doesn’t mention how the fix is implemented, whether it only applies to MAPI clients when starting and whether there is a dependency to different Outlook MAPI client revisions and/or configurations…

      • Hi Martin,

        Good catch that proves that it’s a) always wise to run the latest version of the software (after testing it, of course) and b) that there’s a mass of detail in the release notes for roll-up updates that describes all the fixes that the software includes.


  8. Frederik says:

    Hello Tony, congratulations, great article.
    Maybe you could give us a clue: we think we have an issue with administrative permissions on the root folder of public folders tree. We get “No existing ‘PublicFolder’ matches the following Identity: ‘\'” when running Get-PublicFolder -Server SERVER1 with any user except the original Domain Administrator.
    We´ve also created a new user as a copy of the domain adminstrator, and we´ve given it ‘AllExtendedRights’, and it still doesn’t work.
    The major problem is that this behaviour only happens in two of our four mailbox servers…

    Something we can check?

    Thanks in advance.

  9. Frederik says:

    Thanks again, we´ll have a look…


    • Frederik says:

      Hello Tony, we have just had an issue related to my latest question: we stopped receiving mail in public folders (all of them replicated in 2 servers) because we shut down one of the mailbox servers hosting public stores. This server was the first listed in msExchOwningPFTreeBL attribute. We´ve managed to delete it clearing msExchOwningPFTree attribute from PF database but, ther is any way to make Exchange automatically reroute incoming mail to PF when “preferred” server fails?


  10. Hemant M says:

    Hi Tony,
    I have a query about public folder calendar here is what I am looking for

    “‘m trying to set up a Public Folder with a calendar that our users can subscribe to in order to stay up-to-date with co-worker’s availability. I’ve mail-enabled the calendar so that people can send meeting invitations (i.e. all-day OOTO messages) to the associated e-mail address, but I need the calendar to autoaccept those incoming invitations.

    I’d prefer not to use a resource mailbox because I want this calendar to be located in the same place as other shared calendars.

    Is this possible w/ Exchange Svr 2010 SP1 (v14.01.0270.001)?”

    Thank you
    Hemant M.

    • I wouldn’t use a public folder for a shared calendar in Exchange 2010. Using public folders in this manner is an old-fashioned and obsolete method that ignores many of the new features incorporated in Exchange 2010 that make shared mailboxes a much more natural foundation for shared calendars. I’m thinking about the Resource Booking Assistant, the Calendar Attendant, and the Calendar Repair Assistant. All of these work beautifully with shared mailboxes but ignore calendars in public folders.


  11. Zachary Haberman says:

    Hi Tony,
    These three articles are wonderful and have helped me better-understand the Public Folders environment a bit more.
    You mention exporting the public folder information to PSTs… I have not been able to find a way to do this from the Exchange 2010 Powershell console, yet you suggest this is possible (as does Klaus). Could you point me in the right direction to do this? Do I have to use ExFolders? We already have ExFolders on our server.

    Sorry for the trivial question, but it is anything but trivial to me.

    Thank You!


  12. Frank says:

    Nice set of articles. I understand that public folders are obsolete, but I wonder how I can replace them. Let’s say you have a support group, sharing Everyone should have access to that mails and should reply as They should see that an issue is solved or replied and even can read the reply.
    I’m new to exchange, but I think that a mail enabled public folder where everyone can mark mails as completed would fit those needs. In my understanding a distribution group wouldn’t fit.

    What is your advise? How would you solve that problem?

  13. Dave-Departed says:

    Great article, Tony!

    I’m looking into setting up the InterOrg Replication Tool between our Exchange Org (2010), and the Org of a sister company (2007 – We are in different forests, and AD trust is in place already), as we have a requirement for them to be able to see our free/busy information, and invite us to meetings…

    We share the same physical building, and as such, we also share a meeting room. We currently have a calendar based in a resource mailbox (or room mailbox, as it says when creating that type of thing!), and we need them to be able to schedule meetings on this calendar too. I read somewhere that, in order for that to happen, we’d need to move the calendar from the shared mailbox to a public folder (which is synced between the 2 orgs, to my understanding). Is that correct? Just wanted to sanity-check myself, really.



    • I think the question boils down to whether you need to grant read-write capability to the calendar. If read access is only required, you might be able to do this by publishing the calendar from the room mailbox, a feature introduced in Exchange 2010 SP1. But if you need read-write access, then I think a public folder is probably the best way to achieve this.


      • Dave-Departed says:

        Thanks for the prompt response, Tony.

        Well, I think that, if they can view our GAL, and invite us to meetings via that, then read/write access to the calendar may not be necessary… As long as they were able to view the calendar for the meeting room (with it remaining as a resource mailbox), that should be sufficient.

        Am I understanding it right?



      • If you’re already publishing free/busy information to the other organization and they can use it to book meetings without having full exposure to the details of the room calendar (in other words, all they want is to book a free time slot), then I would leave things as they are, if only because you can use the calendar scheduling assistants in Exchange 2010 to manage the room calendar more elegantly than is possible with a public folder.


      • Dave-Departed says:

        We’re not currently doing anything at all right now, all we have is an already-established AD trust between the 2 forests.

        It was my intention to use the InterOrg Replication Tool to give the sister company access to the room calendar (they need to be able to view the calendar, and also book free slots, that’s the only requirement at this stage) by moving the calendar to a public folder (which would then be synced from the Publisher server in our Org to the Subscription server in the sister Org). But are you saying I can give them the minimum access that I described above, without moving to a public folder? If so, then I’ll need to learn more about the Exch 2010 calendar scheduling assistants!



      • Yes, if you have free/busy in a public folder, you can publish it to the other organization using InterOrg.


      • Dave-Departed says:

        But if I want them to be able to book a meeting in that calendar, I can’t leave it as a Room Mailbox (not in a public folder), right?

      • Not in a public folder, no. A room mailbox has its own calendar and its free/busy data will be published and shared like any other (human) mailbox. The users in the other organization can book a meeting in the calendar of the room mailbox by sending a calendar meeting request to the mailbox… maybe after they have looked up the free/busy data to see if the desired time slot is free.


  14. Andreas says:

    Hello Tony,
    great article, even great book.

    Maybe you can help me with one question:

    I have a E2k10 org with public folders. I like to share Free Busy using Public Folder (IOREPL). I know Outlook 2003 clients are updating the F&B PF on a regular base. How does the F&B PF get updated using Outnlook 2010? Outlook 2010 is not updating the F&B anymore – or?


  15. Amit says:

    Hello Tony, First of thanks for the gr8 Article

    I am having small doubt , that while assigning a user to a PublicFoldermanagement Group will he able to create Subfolders into the public folder hierarchy or Not.. Or do we need to set client permission as Owner for the user to create the subfolders. I have undergo few good documents but while checking the Video from J Peter Bruzzese where he is adding the user to the publicfoldermanagement group and then user is able to create the subfolders so just wanted to clear my doubt, If that does not work mean to say adding a user to the Public Folder management group and after that he is unable to create a Subfolder then what could be the reason?? i know will be related to permission only but if ant thing else i need to look for.

    Thanks again..

  16. Gustavo says:

    I need deny a chil domain ( in OWA to see any public folder of root domain (, how can i do that ? actually its a project to host online archiving for external company wich only consults your historical mails into separate OWA (second OWA in another ports, example

  17. Meraj says:

    I want to decomission my child domain having mail PF objects in MESO container since Exchange 2003 was installed. I have now Exchange 2010 installed in root domain but child domain mail enabled PF objects are not showing as mail enabled. How to move objects in MESO container of Child domain to the meso container of the root domain? After moving the PF objects from child domain to the root domain, will all the mail enabled PF’s will be showing as mail enabled from EMC or EMS of Exchange 2010. If this is not a solution, then if I mail enabled a PF from Exchange 2010 ESM or EMC (its appears in the MESO container) and delete the PF object from the MESO of child domain, will it cause any mail flow issue?

  18. Tara says:

    I just wanted to say that this is a great article, but I cringed when I read the command for removing ‘Anonymous’ permissions. I have learned through experience and support calls with Microsoft that you should NEVER EVER remove either the Default or Anonymous from the list of permissions on Public Folders (or any Mailbox folders, either, for that matter), as doing so can cause permission issues overall.

    Here is an article that talks about how to restore the permissions if they are accidentally (or purposefully) removed:

    So, instead of removing either of those entries from the permissions, simply change them to ‘None’, which will accomplish the same thing without causing other problems.


  19. Jiri says:

    Thank you for a great article!

    We have been using PF from Exchange 5.5 to Exchange 2010. The first big problem for us is migration from Outlook 2007 to 2010. In previous versions of Outlook the root public folder is named “\Public Folders”. Starting with Outlook 2010 the root public folder is named “\Public Folders –” where is the connected user’s primary email address. And we use a lot of documents (publish in PF)with links to another documents in public folders.

    Please don’t you know a way to use these static links in Outlook 2010?

    Thank you for your answer.


  20. Pingback: How To Add Public Folders In Outlook 2011 | Information

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.