Do Not Use Remove-PublicFolder To Remove A Public Folder Database
About once a week, someone comes to me about a case where a customer has accidentally deleted all their public folders when they were just trying to get rid of one public folder store. This happens because of threads or blog posts where someone suggests using some variation of this command:
Get-PublicFolder "\" -Recurse -ResultSize Unlimited | Remove-PublicFolder
The first part of this command returns every public folder in the hierarchy (except for System Folders, which are under \Non_Ipm_Subtree). It returns every folder in the hierarchy, not just the ones that have replicas on a particular server. The second part of this command deletes those folders out of the hierarchy.
Yes, it deletes them. I don’t mean it just deletes them off of one particular store – that would be removing or deleting a replica. Remove-PublicFolder deletes the folder, just like if you go into Outlook, navigate to the folder, and choose Delete.
Of course, the deletion of the folder can take up to 15 minutes to replicate to the other public folder stores, so some customers get lucky. They run the command, then immediately run Remove-PublicFolderDatabase and delete the database before it has a chance to replicate. In that case, you only lose the directory objects for mail-enabled folders, so if you don’t have any mail-enabled folders, you may not even notice a problem.
In other cases, customers get very unlucky, and the change replicates immediately, wiping out every public folder on every public folder server throughout the entire organization.
If you get nothing else from this post, please just remember that Remove-PublicFolder deletes the public folder, and that change will replicate to all the other public folder stores.
So, what should you do if you are trying to remove a public folder database, and it’s telling you something like this:
Remove-PublicFolderDatabase : The public folder database specified contains folder replicas. Before deleting the public folder database, remove the folders or move the replicas to another public folder database.
In that case, you should read my post on the Exchange Team Blog from several years ago:
The bottom line is that if you’re getting that error, you should use Get-PublicFolderStatistics to see which folders have not replicated off that store. The replica list on those folders needs to be changed so that you've added some other server, if there wasn't one already, and removed this server. This can be done with Set-PublicFolder, or MoveAllReplicas.ps1, or PFMC, or ExFolders, etc. Once you've changed the replica list, allow some time for replication.
Unfortunately, in many cases, customers change the replica list and wait, but the folders are still sticking in Get-PublicFolderStatistics. If those are folders you don’t care about, like OWAScratchPad and such, then feel free to delete them with Remove-PublicFolder (or Outlook, or MfcMapi, or PFMC, etc). If those are folders you do care about, you should confirm whether all the data you wanted replicated off. In most cases, they will be stuck because of a few bad/corrupt items that don’t want to replicate.
If you have folders that are stuck because of a few corrupt items, you have a few options. You can delete the bad items, which will allow the replica to gracefully remove itself via the normal replica removal process. You can dismount the database and delete it with ADSI Edit, losing any data that didn’t replicate off, and possibly breaking age limits for any folders that still had replicas there. But either of those options is probably better than piping the results of Get-PublicFolder to Remove-PublicFolder, which runs the risk of deleting the whole hierarchy throughout your environment.
Comments
- Anonymous
January 01, 2003
... which is exactly why this post says DO NOT do it. - Anonymous
January 01, 2003
Are you stupid? It is delete ENTIRE public folders from all servers!!! - Anonymous
January 20, 2015
Hi Bill - how would I get rid of objects in a public folder that are there because of a failed 2003 to 2010 migration. Still want the public folders but want to get rid of the ghost objects.
tks
Rick - Anonymous
January 20, 2015
Found a solution. Just used the Public Folder Management Tool found in the Toolbox option in the Exchange Management Console. - Anonymous
July 08, 2015
Bill, I used .Moveallreplicas.ps1 –server oldservername=old2010 -newserver newservernamehere=new2010, get-PublicFolderStatistics still show there are two offline address list folder on the old server. I cannot get rid of it even the old server never be listed as a replica of the public folder. I also use .ReplaceReplicaOnPFRecursive.ps1 -TopPublicFolder "fullpath of the offlineaddressbook" -ServerToAdd Server02 -ServerToRemove Server01. the command run successfully but the folder still show get-publicfolderstatistics (I disabled publish the offline address book to public folder) - Anonymous
July 08, 2015
Hi Harry, the fact that those two folders won't disappear means that it thinks it has content for them that has not successfully replicated off. Your choices are to either troubleshoot the replication problem, or delete those two folders. If you decide to troubleshoot the problem the PF GWT might help: http://aka.ms/2003pfgwt (this actually covers 2007 and 2010 as well). - Anonymous
July 08, 2015
Hi Bill, thank you for your quick reply. it seems they are orphaned replicas on the server since I use get-publicfolder "non_ipm_subtree"the offline address book full name" |FL replica the server is not on the list. Is there any other way to remove orphaned replicas from local server? - Anonymous
July 08, 2015
Hi Harry, that behavior is actually expected. When you remove a server from the replica list, the folder does not disappear from Get-PublicFolderStatistics until the PF database is able to confirm that all the content has replicated off. If the content has not replicated off, or if the process of confirming the content has replicated is somehow broken, then the folder will continue to appear in Get-PublicFolderStatistics. This is in order to prevent data loss. So you can either identify and fix the issue with replicating the content off, or you can delete the folder. A third, worse option, is to forcibly remove the database with ADSI Edit, which I do not recommend. - Anonymous
July 08, 2015
Hi Bill, I know the replication is working fine, since once I changed the replication schedule for the public folder, it replicates other servers within our org. - Anonymous
July 08, 2015
Hi Bill, BTW, get-publicfolderstatics is supposed to get subtree of the offline address book, says, version 2, version3 ..., but on the server I don't see the sub folders at all. only the two top offline address book names - Anonymous
July 08, 2015
we are planning to delete the folders. I will let you know if this works. - Anonymous
July 08, 2015
Get-PublicFolderStatistics is not supposed to get the subtree, it is only supposed to show the folders that still have instances on that database. The fact that it is showing only the top-level folders means that replication for the subfolders did succeed and those were gracefully removed. But for some reason, replication of the top-level folders failed.
When you remove a replica, there are 4 steps it has to go through to remove the folder from public folder instances. The PF GWT walks you through troubleshooting those steps, as well as my old blog posts. The fact that the folders are still there means that one of those steps failed for each of those folders.
It still comes down to the options of either 1) troubleshooting and fixing replication, 2) deleting the folder, or 3) forcibly removing the database. Fortunately, since these are just OAB folders, the data is expendable and can easily be regenerated. So deleting them is probably the best option. - Anonymous
July 09, 2015
Hi Bill, Thank you for your info. I deleted subtree version 2, version3, etc yesterday and replicate with our org. and it comes back today. This morning, I removed these two unused offline address books from EMS. It seems it will take up to a week for system to remove the OAB instances from public folder. Is this true?
http://blogs.msdn.com/b/dgoldman/archive/2009/05/20/unable-to-delete-the-oab-system-folders-in-exchange-2007.aspx