Exchange Server 2007 Public Folder Deletion: A Halloween Zombie Story

In the United States, we celebrate Halloween on October 31. The point of Halloween varies depending on your age: for parents and young children, the holiday revolves mostly around extorting candy from neighbors. For many other people, Halloween is about scary creatures, such as mummies, space aliens, and zombies. Speaking of which, zombies are the topic of this week's UPDATE, so grab a candy bar and prepare to be scared. Imagine an episode of The Twilight Zone that goes something like this . . .

It was a dark and stormy night, but Joe Admin was warm and comfortable in his brightly lit office. "Just a few more minutes," thought Joe happily, "and I'll have removed this public folder store from my Exchange 2007 server—then I can go home!" A streak of lightning flashed outside the windows, and he could feel the distant low rumble of thunder vibrating through his feet. Alas, a strange sense of foreboding made Joe shiver as he opened Exchange Management Shell and typed the commands to remove his public folder database.

He pressed enter. Suddenly a shriek burst unbidden from Joe's mouth. "What do you MEAN there are still replicas?" he sputtered. "I removed all the replicas already!" Fade to black, cue The Twilight Zone theme.

Joe's just been bitten by a common misbehavior of Exchange Server 2007 RTM. It sometimes insists that there are replicas of a public folder in a public folder database, even when no replicas are visible. As far as I can tell, this is a bug, but knowing that doesn't help get rid of the replicas. I've run into this problem a few times in test environments built using beta versions of Exchange 2007, but my coworker and fellow Exchange MVP Devin Ganger recently ran into it when trying to remove the first Exchange 2007 server from an environment built using only the bare default settings.

Devin tried using Exchange Management Shell to find replicas. He entered these commands:

Get-PublicFolder  -Recurse | ft Name,Replicas
Get-PublicFolder NON_IPM_SUBTREE -Recurse | ft Name,Replicas

But he got no results, indicating that no replicas were present. However, his attempts to remove the public folder database came to naught, even after the standard tricks: Setting the mailbox databases to use a different public folder store; stopping, then restarting the Exchange Information Store service; and even rebooting the server had no effect.

However, another Exchange MVP, Ilse Van Criekinge, found a solution. The trick is to remove all the replicas from the default path, remove all folders from the NON_IPM_SUBTREE object, then remove the database itself. This sequence requires three separate Exchange Management Shell commands. To get rid of all replicas in the default path on the server named "EX2007," use the following command:

Get-PublicFolder -Server EX2007 "" -Recurse -ResultSize:Unlimited |
 Remove-PublicFolder -Server EX2007 -Recurse -ErrorAction:SilentlyContinue
 -Confirm:$False

Note the ErrorAction and Confirm parameters, which are set to force removal, without confirmation, even if errors occur. Next, we do the same thing to the NON_IPM_SUBTREE folders:

Get-PublicFolder -Server EX2007 "Non_Ipm_Subtree" -Recurse
 -ResultSize:Unlimited | Remove-PublicFolder -Server EX2007 -Recurse
 -ErrorAction:SilentlyContinue -Confirm:$False

Now that all the replicas really are gone, we can remove the public folder database with this command:

Get-PublicFolderDatabase -Server ex2007 | Remove-PublicFolderDatabase
 -RemoveLastAllowed

Note that this command assumes that you have only a single public folder database on the target server.

Why are all three steps necessary to remove a public folder database? At this point, I don't know; it appears that some system folder replicas aren't removed when you manually remove replicas. Microsoft is investigating this, so perhaps we'll see a fix for it before it's time to get out the Thanksgiving decorations. In the meantime, you can at least avoid starring in your own version of Invasion of the Public Folder Zombies. Actually, that's a Halloween movie I'd pay to watch!