Recovering Public Folders After Accidental Deletion (Part 1: Recovery Process)


This two-part blog series (EDIT: go here for Part 2) will outline some of the recovery options available to administrators in the event that one or more public folders are accidentally deleted from the environment. The first part will explain the options, while the second part will outline the architectural aspects of public folders that drive the options.


In older versions of Exchange, mailbox and mailbox database recovery was a long, complicated process involving backups, recovery servers, and changes to Active Directory. Successive versions of the product have introduced more and more functionality around recovery (recovery storage groups/databases, database replication, etc.), and we’re now at the point where restoring a mailbox is a seemingly trivial operation, and restoring a mailbox database is almost unheard of. But mailboxes aren’t the only data stored on Mailbox servers in Exchange Server 2010, and the procedure for restoring public folders and public folder databases differs greatly from the mailbox procedure.

Review of Recovery Options

The first two recovery options are detailed either in TechNet or elsewhere on the Exchange team blog site, so I’ll simply list them here and then move on to the real purpose of this blog.  The recovery options for public folders and public folder databases in Exchange Server 2010 are as follows, from the easiest to the most complex:

  1. Recover deleted folders via Outlook (detailed in

    Note: Exchange Server 2010 Service Pack 2 fixes an issue where users were unable to use Outlook to recover deleted public folders. This is another reason to upgrade your Exchange Server 2010 systems to SP2 at the earliest opportunity.

  2. Recover deleted folders via ExFolders (
  3. Recover folders via public folder database restore.

The first option is the easiest and most obvious – if an end user accidentally deletes a folder, he or she should be able to undelete that folder using Outlook. Failing that, an administrator should be able to use ExFolders to recover that folder. But what if these options won’t work in your situation? What if the end user didn’t realize he or she deleted the folder, and a month has passed? Or what if your organization has changed the retention settings for deleted public folders, and essentially eliminated the dumpster?  How do you recover public folders in this case?

Recovery Options

At the heart of public folder recovery is a painful truth: you can’t delete a public folder from the organization and recover it by simply restoring an older version of a public folder database. If you restore a public folder database from backup and place it back into production, you’ll see the public folders only until the server receives replication messages. Because the public folder hierarchy – the list of all folders in the environment – no longer includes the folders which were deleted, the target server has copies of folders which, from Exchange’s perspective, don’t exist. As soon as that public folder database receives a hierarchy update, it will see that those public folders aren’t present in the hierarchy, and the store will delete the public folder again. Since you can’t edit the hierarchy via the Public Folder Management Console (or even via adsiedit.msc), you can’t manually add that public folder back in. So, given this limitation, how do we recover that public folder?

Consider the following points:

  • If you don’t replicate every folder to every database, you would need to delete all current databases and then recover from backup any database that contains unique content.  This only works if you have recent backups, of course, and would also require that you export any content generated since that backup, since you’re going to delete all of the existing databases. The deletion is necessary because if a restored public folder store receives hierarchy replication from one of the existing public folder stores, the whole exercise is for naught.
  • If you do replicate all folders to all stores in the environment, you can delete all stores and just restore one database, then replicate the content from that database out to the other servers. Again, this depends on all databases having duplicate content, and you must delete all existing databases before restoring the one from backup.
  • You can restore a backup of the public folder database to an isolated Exchange environment, connect to the public folder database with Outlook, export all content to a series of PSTs, create new folders in the production environment with the same names as the deleted folders, and then import all of the content. This is obviously a somewhat manual process, and most administrators aren’t going to want to do this.

Recommended Recovery Procedure

Thankfully there is a much easier process which can be performed in-place and with a minimum of fuss.

  1. Select one of the existing public folder servers in the environment. [Using an existing server simplifies the process a bit.] You will isolate this system from its replication partners, so choose a system that doesn’t serve as the source for a lot of content which needs to be replicated.
  2. Using Registry Editor, set the value of the Replication registry key (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public- <GUID of Public Store>) to 0(zero).

    Note: You may need to create this DWORD key if it doesn’t already exist. Further information on the Replication registry key is available in the article, “Replication does not occur for one Exchange server in the organization” ( This registry key also applies to Exchange Server 2007 and 2010.

  3. Restore the public folder database in place using your normal restoration procedure.
  4. Using an Outlook client, log onto a mailbox which uses the restored public folder database as its default public folder store (this is necessary in order to see the restored folders). If you don’t have a mailbox database which uses that public folder database as its default, either create a new mailbox database (recommended) or change an existing mailbox database to use the newly-restored public folder database.
  5. If necessary, click the Folders icon at bottom left of the Navigation screen, and then expand the public folders node.
  6. Copy each of the folders you wish to restore to another location within the public folder hierarchy. If you’re restoring an entire hierarchy, you can simply Ctrl-click and drag the root folder to make new copies of all subfolders. Although the new folders will have similar names to the originals, the underlying folder IDs (FIDs) are different.
  7. Once you’ve created copies of all of the folders, verify that the replica lists include all desired targets (and reconfigure as appropriate).
  8. At this point, it’s now safe to reintroduce that server into the production environment. To do so, dismount the public folder database, delete the Replication registry key (or set it to 1), and then remount the database.
  9. As soon as hierarchy is replicated to the server, the original folders will once again disappear, but the copies of the folders will be replicated to all replication partners.

You may need to add mail-enabled public folders back into distribution groups, as their SMTP addresses will likely be different from those on the original folders. End users will also need to recreate public folder favorites in Outlook.


Recovering from accidental public folder deletion can be difficult, especially if you don’t take hierarchy replication into account. By restoring into an isolated environment, and then cloning the folders to be restored, you can work around this limitation and restore the missing content. In the next blog entry, I’ll explain the underlying architecture of public folders (including replication, change numbers, and the replication state table) to show why these steps are so necessary.

John Rodriguez
Principal Premier Field Engineer
Microsoft Premier Support

Comments (10)
  1. Karsten says:

    Thank your for the recover Information. Some time ago we tested recovery of public folders with a ms engineer. He made us aware that the replication wont happen if we recover public folders. We gave it a try anyway and the recoverd public folders behaved as normal. Is it possible that a third party backuptool (in our case commvault) is able to recover in place and everything works fine without manual actions?

  2. Exfolders 'Recovery Partially Succeeded' says:

    Hi Guys

    I am using ExFolders with Exchange 2010 SP2. When i try to recover a deleted Public Folder i have the Error 'Recovery Partially Succeeded'.

    Exchange 2010 SP1 Update Rollup 3 -> Recover deleted Folder with ExFolder works

    Exchange 2010 SP1 Update Rollup 4 -> Recover deleted Folder with ExFolder does NOT work

    Exchange 2010 SP1 Update Rollup 5 -> Recover deleted Folder with ExFolder works

    Exchange 2010 SP1 Update Rollup 6 -> Recover deleted Folder with ExFolder does NOT work

    Exchange 2010 SP2  -> Recover deleted Folder with ExFolder does NOT work…/c89c2031-84c3-4bd0-b8a7-bb04790a8f0c…/restore-public-folders-and-items-with-exfolders.aspx

    Regards Andres

  3. Inlove says:

    you are my hero, John. Thanks for posting this awesome article.  I needed to recover some deleted public folders today and this helped immensely.

    PS – Where can I get some puka shells?

    your fan, Robert

  4. John Rodriguez [MSFT] says:

    @Karsten:  It may be possible for third-party tools to increment the change numbers on individual folders to ensure that they're not re-deleted after hierarchy replication.  It's more likely that the tool simply copied the folders (creating new ones with identical names) into the database rather than actually restoring them.  Part 2 of this blog (which should be out soon) will go into the mechanisms of replication – hierarchy, content, change numbers, change number sets, replication, and backfill.

    @Exfolders:  From reviewing the thread it looks like there are multiple issues being discussed.  There was a MAPI recovery error, which was resolved in SP2, but there's also a large number of store issues (which often prompt "Recovery partially succeeded" and can't be resolved without tracing and thus a support call).

    @Robert:  You should be able to find pukka shells in the swap meet across from Aloha Stadium on Wednesdays and weekends. :)

  5. ExFolders says:

    Hi John,

    Thank you for the Feedback about the ExFolders 'Recovery Partially Succeeded' issue.

    I have diffrent Exchange Servers in diffrent Domains – all upgraded to Exchange 2010 SP2. The Issue is on ALL Servers – so i think this more a "general" Problem.

    Regards Andres

  6. Der Eisenmann says:

    Thanks for great article! It´s always great to have a good way to recover before anything happened…;-)

    By the way…we use Ontrack Powercontrols to recover any public folder. Works easy and fine. I tried a lot of tools but this is the most reliable one.

  7. Andrei G [MSFT] says:

    Thanks John, great post!

  8. Arunas says:

    @Andres: We need to wait until SP2 RU1 will be released – recover will work again :) Or maybe in SP2 RU1v4 :) ,but who cares about these small details and reads all release notes :))

  9. MikeBaker says:

    update DL's with PFs is abit short – alot of public folders receive mail direct from systems or external.

    a process of updating these to be exact needs to included.

    also what is the impact on public folder rules?

  10. John Rodriguez [MSFT] says:

    @Andres, Arunas:  As I mentioned above, there are a number of store-related issues which will cause the "recovery partially succeeded" error, and the only way to really resolve the problem is through a support call.  If you want to track down the root cause, you should open a case with Microsoft Support who will help you configure tracing and analyze the results.

    @Der Eisenmann, Andrei G:  Thanks for the feedback. :)  

    @MikeBaker:  Thanks for the comments.  You're absolutely right: a lot of customers use mail-enabled public folders as a workflow or feedback mechanism.  As a matter of fact, I "cut my teeth" at a company in Denmark who have the world's largest public folder environment and are known within Microsoft for using PFs as just this type of workflow mechanism.  But let's be clear: the recovery mechanism I outlined in the blog is for those cases when you can't recover via Outlook or ExFolders.  This procedure is for situations when you have no choice but to recover from backup (which usually means you're in dire straits) and need to do so accurately and effectively.

    So on to the technical details … If you clone a mail-enabled folder, the alias will most likely have a number appended to the alias, so mailfolder would become mailfolder1, and its email address would likewise change from to  This occurs because Exchange won't allow you to create two objects with the same alias, and the email address is built on the alias itself.  End users never see the alias, just the folder name, so this doesn't impact them directly.  [It's this same alias shift that would lead to the problem with distribution group membership.]  You could probably run a script looking for numerical values at the end of the email address (presumably using a regex), enumerate those objects, and then perform a name change operation against them.  I know this is less than optimal behavior, but again, you should only perform this sequence if all else fails.  It's not the preferred option (which would be a quick and clean undelete with Outlook or ExFolders), so may entail a little cleanup afterwards.

Comments are closed.