| Public folder management seems very simple on its face: you create a public folder and people post to it, then Exchange automatically replicates the folder data from point to point. However, there's an awful lot of hidden complexity lurking beneath the simple exterior. It's not uncommon for medium- and large-sized organizations to have thousands of folders with items in them, often with folders that by themselves take up gigabytes of space in the information store. As the number and size of public folders in use increases, so does the likelihood that you'll actually have to maintain and manage your public folders instead of just leaving them alone. Public Folders Versus Mailboxes Exchange separates public folders from mailbox folders using a simple design: public folders live in their own separate databases. These databases are very similar in structure and behavior to mailbox databases, but there are some important differences. Individual public folders may be replicated to one or more servers. All replicas are treated equally; there's no master copy of a given folder. When someone changes a public folder item in one replica, that change is passed to the other replicas, and Exchange will make an attempt to resolve conflicting changes on its own when possible by comparing modification times and update sequence numbers to find the newest change. Every Exchange server has access to a copy of the public folder hierarchy, a structure that defines the organization and nesting of folders. An individual server may have replicas of zero or more folders, but it will always have the hierarchy; one common cause of public folder access problems is out-of-date hierarchy information on one server. Like mailboxes, public folders have access control lists (ACLs) that define who can and cannot access data. However, the ACLs themselves are different because public folders support a number of individual roles (including contributor, reviewer, and editor) that mailboxes do not. Accordingly, setting permissions on public folders can be more complicated than doing so for mailboxes. Public folders, by default, support access for any authenticated Exchange user, whereas mailboxes are by default only accessible to the associated Active Directory user object.
Individual items in public folders, and the folders themselves, carry ACLs that control who can and cannot manipulate them. Unlike standard mailbox items, public folder ACLs can be set by role. These roles (which include Author, Editor, Contributor, and Reviewer) combine various permission to read, change, and create or delete items, whereas mailbox folders have a more limited set of potential permissions. Another quirk of public folders is that there can be more than one hierarchy on a server. The default MAPI top-level hierarchy (TLH) is the only set of public folders that MAPI clients can see. However, Exchange 2000 and Exchange Server 2003 let you create additional non-MAPI TLHs. Folders in these additional TLHs are available through OWA and WebDAV, so they are commonly used to host public folder-based applications. Public Folder Replication The public folder hierarchy is always replicated, but each server maintains its own replica list indicating what folders it hosts locally and which updates it's seen for a given server. Replication is a fairly complicated process; Appendix E of the Exchange 2003 Administration Guide (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/admingde.mspx) provides a very detailed 25-page explanation that we won't attempt to reproduce here. Instead, we'll summarize how the process works; for more detail, download the guide. A user makes a change to a public folder. This change can be almost anything: adding or removing a public folder item, editing an existing item, or modifying the item's properties all qualify. Note that when a public folder item is replicated, the entire item is replicated; there's no mechanism for replicating only the field or attribute that was changed. That means that making a one-byte change to a 400 KB message will result in the entire message being replicated. The information store on the public folder server creates a change number for the update. This change number is nothing more than a version indicator that other public folder servers can use to check whether they already have a particular update. The IS batches multiple changes into a replication message (the size of which you can control). The replication message is sent to all other public folders servers that host replicas of the affected folder; it finds replicas by looking at the organization's public folder hierarchy object. The message itself is just an ordinary-looking mail message, except that it's packed with indecipherable binary junk. Exchange treats these replication messages as system messages, since they're addressed to a system mailbox. When the replication schedule indicates that it's time for an update, the store sends all accumulated replication messages out to other servers. As the Administration Guide points out, the Exchange transport engine is responsible for getting those messages to their destination; the #1 cause of public folder replication problems is mail-flow failure between the selected servers. The receiving server accepts the replication message and extracts the list of change numbers in it. The list of change numbers is compared to the existing items' change numbers. As a result of this comparison, the store ends up with a list of updates (from the replication message), which it then applies. As each update is applied, the store updates the local folder to reflect the new changes. If the change number list indicates that other replicas have a newer update than the one available on this server, the server requests a backfill.
The idea behind replication backfill is simple. Let's say you have three servers with replicas of the same folders: A, B, and C. A and B are in your office; C is behind an ISDN line at your factory in Shenzhen. You make a change on the folder replica housed on A; let's call that change number 1000. It's replicated to B, where another user makes change 1001. The replication message from B gets to C first, so C can see change 1001 but not change 1000. It will send a request to either A or B for change 1000, then apply it when it arrives. This backfill mechanism is also used to fill a newly created replica with content: when you add a replica, the new replica's server essentially sends a backfill status message asking for all changes. The receiving store obediently assembles those changes into a series of replication messages and sends them back. However, Exchange only sends these backfill messages every 12 hours, so it's possible for an update like this to take as long as 36 hours to complete. The System Public Folders Most users think of public folders as something created just for users, but there are several system-created public folders whose presence and proper handling are critical to getting complete Exchange functionality. These folders can exist on any Exchange server in the organization; you must have at least one replica of each. Adding multiple replicas provides redundancy, with some potential side effects that I'll mention in a minute. The two most important special folders are: The Schedule+ Free/Busy folder contains free/busy data for each user. This data is actually just a long string of bits, where each bit indicates whether the user is free or busy for the associated time period. This bit vector can be generated in one of two ways. For Outlook users, Outlook can publish it (as described in MS KB 196885), which it does at 15-minute intervals. For OWA, Entourage, IMAP, POP, or OMA users (e.g., everyone except Outlook MAPI users), the Exchange system attendant service uses CDO to retrieve the free/busy data and post it to the Schedule+ folder. If you don't have any copies of this folder (i.e., if you accidentally delete the only one), you'll find that users cannot see each other's free/busy status. The easiest solution to this is to add more replicas, but then you have to be carefuldepending on how often your users update their calendars, and what your replication schedule looks like, two users who are accessing two different replicas of the folder may see different data when they look up free/busy information for a third user. The Offline Address Book (OAB) folders store the offline copy of the global address list (GAL). There are actually several versions of the OAB format, but Exchange automatically generates the appropriate OAB formats and stores them for you, so you can treat all of the OAB folders as identical. Exchange generates a full OAB and then a series of delta updates to it; Outlook will automatically download these updates every 24 hours, or when you force it to do so. The biggest issue most sites encounter with the OAB is the occasional need to rebuild it due to corruption, and the second biggest is the load imposed on highly consolidated servers when lots of clients try to download the OAB at once.
There are some other special folders that you may run across, too: The OWAScratchPad folder (whose actual name includes a GUID) is created when a user adds an attachment to a public folder item. The attachment and post are stored in this folder until they're completed, at which point, they're actually posted to the target public folder. The StoreEvents folders (whose names also include GUIDs) hold registrations for event sinks in public folders (although there are corresponding StoreEvents folders inside each mailbox store). The Schema folder and its children are used for controlling the database schema used by the Exchange OLE database interface. Don't mess with them. The Internet Newsgroups folder is semi-special; it will be present by default in almost all Exchange organizations, but unless you're using the NNTP service to post USENET articles to it, it will be empty and may safely be hidden (ESM won't allow you to delete it). If you are using NNTP, you'll also see an NNTP Control folder, which is where USENET control and cancellation messages are stored.
Some Useful Public Folder Tools Exchange System Manager is where you'll probably do most of your public folder foolery, but Microsoft has some other useful tools that are, regrettably, not as widely available as they should be. All of these tools are available for free if you call Microsoft PSS. Some of the recipes in this chapter will make use of them, so you might want to have them handy: The command-line PFAdmin tool (PFAdmin.exe) can list or set ACLs, rehome folders, and list or set the contents of the replica list on the server. That makes it a very useful tool, although it only works on the MAPI TLH. It's also available on the BackOffice Resource Kit (BORK) 4.5 CD. The GUI-based PFInfo tool (PFInfo.exe) examines a server and generates a text report of its pubic folder permissions and replicas. This is great for change control and documentation; it's also very useful when you use this output as input to PFAdmin to set permissions uniformly on multiple folders or across multiple servers.
 | PFInfo and PFAdmin are older tools that aren't supported by Microsoft for use with Exchange Server 2003. PFDAVAdmin is a much more powerful (and reliable) tool, and you should use it whenever possible instead of the older tools. The only time to use PFInfo and PFAdmin is if you simply must have a command line to do the job, or if you're working with an Exchange 5.5 server. |
|
The Public Folder Migration Tool (PFMigrate.wsf) is a script that (as described in Recipe 9.1) can automatically move public folders from one server to another. It's smart enough to do so even if the servers are in separate routing groups or sites. It's available on the Exchange Servber 2003 product CD and as part of the Service Pack 1 (SP1) download. The PFDAVAdmin tool (PFDAVAdmin.exe, currently at Version 2.3) is a GUI-based tool written with the .NET Framework (which has to be installed for the tool to run). Unlike PFInfo and PFAdmin, PFDAVAdmin uses WebDAV instead of MAPI, so it can work with any TLH, not just the MAPI one. It also does a lot of nifty stuff (which is why it has its own recipe). From its documentation, here's what it can do: Modify folder permissions on folders in the MAPI tree using an interface similar to ESM. This usually isn't necessary, but it can come in handy since you can use this tool in places where you might not have ESM installed. Propagate the addition, replacement, or removal of one or more ACEs down the public folder tree without overwriting the entire ACL. Fix noncanonical or otherwise damaged discretionary ACLs on folders in bulk. For example, if you've fooled with public folder permissions by setting them using Windows Explorer on the M: drive, you can easily fix them with PFDAVAdmin. (Exchange Server 2003 hides the M: drive specifically to avoid this kind of problem.) Export and import folder permissions on both public folders and mailboxes. Export and import replica lists for a given server. Propagate changes to the replica list down the tree without overwriting. Check for and remove item-level permissions in bulk. Check to see what event sinks are registered on a server. Set public folder limits and quotas that are larger than the limits imposed by the ESM GUI. Display and modify folder properties in bulk.
|
