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.