Last week's column on zombie public folders drew some very interesting replies ("Exchange Server 2007 Public Folder Deletion: A Halloween Zombie Story," October 25, 2007). A number of readers wrote to express their frustration with the problem of deleting public folders, and their frustration is perfectly understandable. Microsoft's Bill Long, a member of the Exchange customer problem resolution team, sent me a great explanation of what's really happening in this scenario, and why the solution I wrote about last week isn't necessarily the best one for all situations.
First of all, this behavior isn't an Exchange 2007 bug; you'll see the same behavior with Exchange Server 2003 if you try to remove a public folder database that still has folders in it. The difference is that the output from Exchange Management Shell's Get-PublicFolder command can be confusing.
The commands I described in last week's UPDATE will remove all public folders in the organization, which might be just what you need in a test environment. However, you probably won't want to use this procedure in a production environment—which is what the readers who wrote in were complaining about. The answer to this problem lies in another Exchange Management Shell cmdlet: Get-PublicFolderStatistics.
As Bill explained, the problem is that when you remove a public folder replica from a server, the server is immediately removed from the replica list so that it won't receive further replication updates. However, the public folder data itself persists in the public folder database until the data is replicated! This behavior is by design; it prevents you from removing a replica before its specific updates have been copied to remaining replicas. In the scenario I outlined last week, if you remove the public folder, you might be able to delete the public folder store—it depends on whether information about folders deleted from the hierarchy have been replicated before you attempt to remove the store database.
Bill pointed out, and I agree completely, that using my original steps in a production environment would be a really bad idea. Instead, you should try removing folders in the usual manner. You won't be able to remove the database it there are still unreplicated folder changes in it. If you only have one server, then you probably don't care, and it's OK to follow the original steps. If you have multiple servers, you should use Get-PublicFolderStatistics to see where the unreplicated instances are. This command returns information about all replicas, even those that are on servers that have been removed from the replica list. In other words, Get-PublicFolderStatistics will show servers from which you can't yet delete the public folder database—just what you want to know.
If you wait for a replication cycle to finish, the folders should then be removable. If replication finishes and you still can't remove a folder, that points to a replication problem that's preventing the public folder updates from reaching other servers that host replicas of that folder. These folders might be system folders (e.g., OWAScratchPad), in which case you can safely remove them by piping the output of Get-PublicFolderStatistics for the specified database to Remove-PublicFolder. However, if Get-PublicFolderStatistics shows "real" folders, you should troubleshoot and fix the replication problem before attempting to delete the store.
The Microsoft Exchange Team Blog has a detailed post about the mechanics behind public folder deletion. Although the post describes Exchange 2003, Exchange 2007 behaves in exactly the same way. Check it out if you've encountered this problem, or if you just want to know more about public folders. Now I'm off to eat some Halloween candy—so far, the Milky Way bars are my favorite!