New Public Folder Administration coming in Exchange 2003 Service Pack 2
Published May 16 2005 04:23 PM 6,878 Views

Here are some of the changes that we are making to Public Folders in Exchange 2003 Service Pack 2 (SP2).

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.

- Dave Whitney

25 Comments
Not applicable
That is great, but would have been even better a month ago when I had to retire two public folder servers :)
Not applicable
Dave,

One thing that my company has always wanted (which has really prevented us from really using PF's heavily) is how mail quotas work with public folders. For example, say we want to give a business unit a PF and give them rights to create as many subfolders as they want, but we want to limit the amount of space that BU can use in that public folder and all subfolers they create. Today this is not possible as each folder gets its own seperate quota. Will this ever change?

Thanks,
Steve
Not applicable
Excellent feature - now if there were only a better way of managing quotas on folders (so the contents of folders all the way down the tree are added in when calculating a quota on a particular folder) that would be great!
Not applicable
These sound like great additions. I really could have used them during my company's migration from 5.5 to 2003.
Not applicable
See the post on the EHLO blog...we will finally be able to propagate one permission change down through...
Not applicable
You are my hero. Seriously. I despise public folders and everything about them, but this is the most spectacular news I've read about Exchange 2003 so far.

Keep it up. :)
Not applicable
Finally it's here - I always wanted to propagate delta changes tp permissions(did it with pfdavadmin)! And also the new "Move All Replicas" Menu is cool - it's nearly equivalent to what "pfmigrate" does. Cool stuff! I'm looking forward...
Not applicable
Not applicable
I wonder that MS still works on PF features. IMHO PF are nothing more than a simple store (like folders in a file systen on a file server), without any funtions to do things like workgroupimg or collaboration with documents. The only positive thing about PF is, that users do not have to leave the OL Client to load a document. When it comes to collaboration with documents, Sharepoint Portal Server or WSS is still my choice.
Not applicable
With regard to quota management: the problem with trying enforce a "hierarchy" quota as opposed to a "single folder" quota is that it may be the case that not all the subfolders are replicated locally. The server can't compute the size of the content in a folder which isn't replicated locally. (This is the same excuse for why we don't support deep searches - the results would be incredibly confusing.) We don't want to store the computed size of the content as a replicated property of the folder itself as that would create a rash of unnecessary hierarchy replication every time any content change happened.

To implement this feature, we'd require full-time connectivity among server so they could each query each other about pertinent information. The PF system doesn't otherwise have this requirement, and implementing it would be a substantial change in architecture.
Not applicable
Are you considering providing a tool/process for tombstone cleanup after public folder deletions?
Not applicable
The big feature that is still lacking is the ability to FORCE Public Folder replication. We're in the midst of migrating over 30 Exchange 2000 servers to 2003. The largest headache in decommissioning the E2K servers is validating and forcing content replication.

That's great that you can't decommission the PF database if it's the only one that holds the replica, but what if the changes haven't replicated off?
Not applicable
<p>
I wrote a column last week on the public folder management improvements in Exchange 2003 SP2. As a guide, I used Dave Whitney's post on the improvements, since none of the other SP2 documentation has been made public.
</p>
Not applicable
You *can* force replication. Right-click the folder you want to replicate in ESM (under the Folders / Public Folders node), then use the Send Contents command. Via script, you can use the Synchronize or SendContents methods, depending on whether you want to sync all replicas on a server or only a single folder.
Not applicable




Hi,










Hi,

 

I’ve hopefully met many of you at TechEd, IT Forum,...
Not applicable
Why Exchnage don't know tthe concept of groups for managing security?

Good work..and good luck!
Lorenzo
Not applicable
TechEd is on in the USA (Orlando, Florida) right now, Steve Ballmer did the opening Keynote which was...
Not applicable
TechEd is on in the USA (Orlando, Florida) right now, Steve Ballmer did the opening Keynote (titled "Enabling...
Not applicable
Folder tombstones: this is a touchy and complicated area. Flushing out tombstones too early runs the risk of folder deletes not being replicated everywhere, while keeping them too long makes recovery from a backup a Big Pain. To that end, we already have a registry key override to cut the default expiry time of 180 days down to whatever you want. We'll also be adding code in the next major version of Exchange to flush out more than the current 500 tombstones during each nightly maintenence cycle.

Forcing replication: Right-click/Send Contents doesn't send any previously unsent data. In the next version, we've changed the text to "Resend Contents/Hierarchy", which is really what it does. However, we do have a "kickstart" feature where you can give the replication engine a poke in the side. Just select the folder in ESM, then on the right side of the page, choose the Status tab. Right-click on each replica and choose "Synchronize Content." This wakes things up and raises a little excitement. It does not, however, truly guarantee that things are going to sync up right away - the replication engine is (by design) very latent and passive. It depends on email flow, and employs reasonable delays in its activity to ensure it doesn't flood your network.

This same kickstart is automatically employed when you remove a replica from a server. The server immediately announces to the world that it's going away and if there's any local data that some other server needs, now is the time to get it. Simply removing a server from a replica list should get the system as excited as it needs to be to get the data off that server as quickly as possible,
Not applicable
This is outstanding and so needed. The only thing better would be to get rid of public folders all together! ;)
Not applicable
Hi Dave, I was wondering if you have made sure PFs authentication scheme problems related to domain trees (sub-domains) are solved for this new SP.
I'm experiencing great frustration having mails sent internally to mail-enabled PFs being rejected since I simply created a sub-domain in my organization.
This’d been documented in KB870585 but the hotfix offered by MS-Support only works on E2K3 without SP1. The KB states there is an other hotfix for SP1s but MS-Support doesn’t have it.
Any light on this issue?

Regards
Not applicable
Great news, I had read about some of this, but was concerned that we would still have to make the settings at each top level folder.

Is there any chance there are plans to provide a user disconnect feature. Some times our users get these orphaned logons and when they reach 32 or more they can no longer log in. I know I can up the limit, or dismount the store, but I wish I could just right click and disconnect the user. Same thing in the mailbox store would be nice though...

Thanks for the info!!!


Not applicable

A frequent topic of discussion with customers is the future of Public Folders, thus I think it would...
Not applicable
Recently MSIT wanted to make some global changes to the retention time of public folders. In the past...
Not applicable
Most helpful URL for Configuring Public Folder Permissions
Version history
Last update:
‎Jul 01 2019 03:05 PM
Updated by: