From a post by Dave Whitney:
Each week, we examine the top Support Services (used to be called PSS) calls and how much it’s costing the company to service these calls. While public folder administration does not by itself compose a high percentage of these costs, a high percentage of the public folder administration issues stem from one single dialog and a complete misunderstanding of what it does.
I’m speaking of the right-click menu item off of a public folder in ESM called "Propagate Settings". What this dialog allows an admin to do is copy particular properties of the selected folder to all of the subfolders beneath it. Seems fairly self-evident, except people are led to believe that delta changes they just made to the selected folder (such as adding a user to the ACL, or making some change to the folder’s replica list) is what will be propagated. Not so! The dialog only copies the current settings to all the subfolders. This usually results in spectacular replication storms if the admin is propping down changes to the replica list.
As a result, we’ve replaced the Propagate Settings dialog with the Manage Settings wizard. The wizard has three gross paths: 1) do things the old way (when you really do want to copy properties to all the subfolders), 2) make a delta change to the folders’ client permissions, and 3) make a delta change to the folders’ replica list. You can add, remove or replace replicas and users, and you can also modify permissions of a single user. So, say you’re interested in moving a hierarchy of folders off of one server onto some other server. You don’t know offhand which folders in that hierarchy are presently on your source server. No problem! Just use the Replace a Replica path through the wizard to replace server A with server B. It’ll only affect folders where server A is presently a replica, so the rest of the folders in that portion of the hierarchy will remain unaffected.
Another high percentage of the public folder-related calls results in admins retiring public folder stores which still had content replicas. They end up losing data either because users had posted data to that store and it never got a chance to replicate out, or that store was the sole replica for some folders.
As a result, we’ve tightened up deleting public stores. You can no longer delete a public store that still has unreplicated data present. You must first move all the replicas to another server (or delete the folders you just don’t want or need to keep). This includes system folders too. The aforementioned wizard is helpful, but is still a pain because the admin would need to right-click each top level folder and run through the wizard. So, there’s now a new right-click menu off of the public store object itself: Move All Replicas. The admin just chooses some other server and voila! all of your replica lists are modified. Note that you can’t delete the store until everything has actually replicated away. Simply changing the replica list is insufficient - the system will confirm when all the data is actually replicated away, and this process could take a substantial amount of time.
This small handful of changes should substantially lower customer headache pain levels, and reduce our public folder support costs to nearly zero.