How to decommission a Public Folder server without losing any data

So you’re standing there in your machine room, staring at all the old machines you’d just love to retire. There’s all this new hot hardware, with a whole lot more storage. You just don’t need all those Public Folder servers any more.

So? Why not just run setup and uninstall the server? Well, setup’s uninstall process makes no attempt to insure data preservation as it does for mailbox stores. The same goes for Exchange System Manager if you just remove the public store. It’s up to you to make sure everything’s been replicated off the database before it’s removed from the world.

That may seem easy enough (and it actually is), but most people assume certain activity which doesn’t happen and they end up losing data. The problem is if the server is a replica for any folders, there exists the potential that a client is connected to this server publishing new data right as you’re trying to decommission it. Also, if this server holds the only replica for some folders, all of that data will be plain lost.

Your first step is to insure no mailbox stores are set to use the aging server for their default public store. This will ensure nobody creates new folders on the server just as you’re trying to decommission it. Changing the setting in ESM by itself is insufficient – you may need clients to log off of Outlook and log back in.

The next step is to use PFDavAdmin (see to simultaneously remove the aging server and add another existing server in the replica sets of all folders. You could do this from within ESM, but ESM doesn’t have any facility for doing this selectively. You could use ESM to broad-scale replace the replica sets of all folders, but that may not be what you want to do. PFDavAdmin will let you replace one replica with another, which will only affect those folders which have replicas on the server being replaced. Note that the tool only works against Exchange 2000 and 2003 servers, so you need to have one of those in your org. Of course, it’s not necessary to run the tool against the server you want to retire – any public folder server in the org will do.

After having done this, view the Public Folder Instances page in ESM for that store. Once the list of folders no longer contains any folders you’re interested in keeping data for, you may safely decommission the database (or the whole server). Note that the process may take a long time – be prepared for it to take a few days, at the least. Also, you will need to dismount and remount the store (after it knows about the replica list changes). This is because the server won’t actually force already connected clients from disconnecting and possibly publishing more data.

- Dave Whitney

Comments (5)
  1. Manuel Nieto says:

    Is this tool still available, if so.. where? I could not connect to MSs PSS FTP.


    Manuel Nieto

  2. KC Lemson says:

    Manuel: Try using a different FTP client from your browser, such as the commandline one in windows. I was able to get at the file fine with the location mentioned in the linked article.

  3. Mailsweeper Guru says:

    We have had lots of problems with the decommissioning of Public Folders, which have led to mail storms of PF replication traffic. How does following this procedure impact on replication traffic?

  4. Dave Whitney says:

    It will actually cause quite a bit of replication traffic. It depends on how much of the data on the store to be retired already exists elsewhere. Anything that doesn’t exist elsewhere will need to be replicated there (which will happen automatically). So it’ll cause enough traffic to get all that data off. There’s also a protocol the stores follow to insure everything’s done, and this consists of 3 or 4 emails per folder being relocated.

    I would be worried if you *didn’t* have a ton of replication traffic when retiring PF stores. Such an occurrence likely means you’ve lost some data.

  5. Anonymous says:

    Wanted to talk about a subject that is very often a source of questions, especially in our Support Services….

Comments are closed.

Skip to main content