7.13 Public folder replication

---

A public folder exists in an organization as a single instance on its home server or as replica copies hosted by multiple servers. The Store performs replication on top of the messaging infrastructure, so connectors must be in place before any replication can take place. When multiple replicas exist, Exchange uses an email-based replication mechanism to move updated content between the replicas. Any replica can generate replication requests, because users with the appropriate permission can apply updates to any replica.

Two types of replication activity exist for Exchange: hierarchy and content. The Store replicates the public folder hierarchy to ensure that all of the servers in the organization that share a public folder tree have a common view of the folders in the tree and their properties. Hierarchy replication involves changes to the hierarchy, such as new folders, folder renames, folder deletes, and any changes that users make to folder properties. You cannot manage hierarchy replication, since this is totally under the control of Exchange. However, you can configure content replication on a folder-by-folder basis to copy the contents placed in the folder (together with all their properties) to all replicas. The Public Folder Replication Agent (PFRA), a process that runs inside the Store, manages both hierarchy and content replication. Note that the Active Directory takes care of replicating the mail-enabled properties of public folders, such as their email addresses.

Microsoft designed public folder replication to:

• Bring data close to users by allowing them to connect to a local replica.

• Make data more available and resilient by keeping multiple copies around the organization.

• Avoid excessive network traffic that would otherwise be required to pull information from single points in the network.

The last point is interesting, because the single point of contact is the model adopted by Web sites and portals. The most obvious disadvantages of public folder replication are that maintaining several copies of information increases the data storage requirements of the system, and it is possible to swamp a network with public folder replication if you allow it to grow in an unmanaged fashion.

The responsibilities of the PFRA are to:

• Maintain folder replica lists so that it knows which servers host replicas of public folders.

• Monitor replication schedules and dispatch replication messages to distribute content according to the schedule.

• Send status messages to other Exchange servers to ensure that data has arrived and content does not need to be backfilled.

• Generate any necessary backfill requests if required to complete the content in any of the folder replicas that it manages.

• Respond to incoming backfill requests generated by other servers.

Replication is an advantage that public folders have over network shares. You can put documents in a public folder and Exchange will replicate the contents to other servers in the organization. You can even replicate documents in public folders between organizations using the InterOrg Replication Utility. Not many deployments have a need to use this program, because a single organization suffices, but it is useful if you need to share data between two or more organizations in the case of mergers and acquisitions, or if you simply need to operate multiple organizations, perhaps because you need to deploy different AD schemas. The free/busy system folder is the favorite replication target, because this allows users in both organizations to see each other's availability for online meetings.

The art of system design is to maximize advantages and minimize disadvantages. Obviously, you do not want to channel thousands of users toward a single folder on a remote server somewhere, but you also do not want to distribute replicas of every public folder to every server in the organization. Therefore, the trick is to create an appropriate number of replicas for each folder you want to share, and then make sure that content replication takes place at the right intervals.

When you consider the replication interval for a folder, you need to think of who are likely to want to access a folder and where they are located, and then consider creating a replica on or close to (in network terms) the server where these users' mailboxes are located. Think of the use that the folder will get. Maybe the folder is going to contain items that users frequently update, or, on the other hand, the folder may contain documents such as policy and procedure statements that the owners review and update once a year. Perhaps the folder holds items for a forms application that requires users to receive updates as quickly as possible, or it captures new items from an Internet mailing list or newsgroup for users to browse. All of these are factors that help you determine how many replicas to create, the servers where the replicas are located, and the replication schedule.

Figure 7.41 illustrates the replication status information for a public folder as displayed by ESM. The local replica (server TLGEXC01) is "In Sync," which means it is fully synchronized with its peer replicas. The other servers report "Local Modified" status, meaning that some data originated from these servers at the noted time and replicated to the connected server. However, I take these status reports with a pinch of salt, since they have never been totally accurate. The only way that you can be sure that replication works is to add an item to one replica and see how quickly it appears in another. Alternatively, wait until someone says there is a problem and then find out if a replica is missing data and why.

Figure 7.41: Viewing public folder replication status.

7.13.1 Creating new replicas

You create new folder replicas by either pushing or pulling. Pushing means that the administrator of the system that hosts a public folder decides on which other servers a new replica of the folder should be created. The system administrator of any server that already holds a replica can push out new replicas of folders to other servers. You do this by selecting the desired folder, opening the Replication property page, and then selecting the new target server(s) to host the new replicas. For example, in Figure 7.42, you can see that the replica already exists on five servers, and the administrator has the option of creating a new replica on another server by selecting it from the list.

Figure 7.42: Pushing a new public folder replica.

The administrator of the target server is not aware of this action. Any administrator can decide to push a replica toward another server. Because Exchange performs replication using the messaging system, as long as there is a valid messaging path between the servers and the "pushing" administrator has the necessary permissions over the receiving server, the content goes to its new home. The only indications that a new replica has been established is an increase in the number of replicas and a growth in the disk space occupied by the Public Store on the target server. Most administrators will not even be aware that a new replica has arrived!

The "push" model is only viable when you have a server that already hosts a replica (remember that Exchange treats all replicas as equivalent masters). Servers that do not already have a copy use the "pull" model. In this case, the system administrator of the server that wants to create a new replica browses through the public folder hierarchies until the desired folder is located. At this stage, you can add the replica using the same sequence as outlined previously. As soon as the change is applied, Exchange will proceed to request the host Public Store to begin transmitting the folder contents to the requesting server. Folder content arrives in a series of messages sent to the Public Store on the target server by the PFRA on the host server, so it may take some time before the local replica is available for user access.

Does it matter whether you pull or push? The answer is that either action is valid and useful, as long as you want to create the new replica and understand the consequences of your action. In most cases, the consequences are no more than an increase in the volume of messages generated within the system. The more replicas, the more messages are required to ship data around for all changes-additions, deletions, and amendments. If you allow the public folder hierarchy to grow without restraint, you create the potential that the sheer number of folders within the hierarchy cloaks valuable data. In the same way, if multiple replicas are created without restraint, a danger exists that valuable network bandwidth is absorbed by unnecessary messages being transmitted between Exchange servers.

It is interesting to reflect on the philosophy inherent in a system that allows uncontrolled distribution of replicas to occur. There is no way that a system administrator can prevent an administrator of another system from deciding that a folder created on his or her system should be pushed over the network, or indeed to create a local replica and pull content from your system. The reverse is true too. There is no method to prevent a remote system administrator from rejecting an attempt to create a replica on his or her server. The replica may arrive, but as soon as the local administrator notices its presence, he or she can remove it, sending the folder back to where it came from.

Implementation plans should address this issue by stating clear guidelines for the creation of replicas. In other words, who can create replicas and the conditions that must exist before you create new replicas. Regular checks should also be performed to see how many replicas exist for each folder, especially those that might contain sensitive information, and where those replicas reside. Finally, you should keep some basic statistics to track the growth of the number of public folders, their use, the users who access the folders, and who manages the access control list for the folders. It is also useful to know who is creating the public folders and have a procedure to allow people to inherit control of folders when the original owners move on to other responsibilities.

7.13.2 Public folder referrals

Replication gets data close to users. The alternative is to force users to come to data held on a remote location, which is what happens when you refer an attempt to access public folder content on a server in another routing group across a connector. One or more replicas of the target folder may exist in the organization. Referrals are most useful if you want to maintain a single definitive set of data rather than replicating it to several or all sites. However, client access to remote data is usually slower than when clients can access a local replica. MAPI clients use RPCs to attempt to connect to a public folder via referral. It therefore makes no sense to refer public folder accesses to a server linked via an extended X.400 or SMTP connection. If you can manage to maintain just one replica of a folder in the organization, then referrals offer a number of potential advantages over replication, including:

• No network overhead is incurred to replicate new and updated content to different servers throughout the organization.

• No latency occurs between the time when changes are made and the same data is available to everyone throughout the network.

• There is no need for conflict handling.

• You do not duplicate information in multiple locations.

By default, connectors permit referrals. Unlike Exchange 5.5, where public folder affinity is a property of a site and you can allocate different sites varying weightings to determine the order in which Exchange will try to reach a public folder replica, Exchange 2000 depends on the weighting allocated to a connector to know how to attempt referrals. If there is only one connector available for a server to use, Exchange attempts to contact a server that holds a replica in the routing group that the connector links to; otherwise, it selects a server in the routing group served by the lowest cost connector. Note that a connector is just a path for messages and plays no role in the actual connection to public folder content, since a point-to- point client to server connection establishes this using MAPI RPCs. If an administrator has set the properties to block referrals across that connector, then the public folder is unavailable. If two connectors are available and both support referrals, the connector with the lowest cost is used.

The situation is different in Exchange 2003, because you can choose how public folder referrals behave on a server-by-server basis. The default referral mechanism continues to use the routing group topology. However, if you know that a server should always connect to a specific public folder server to fetch content, you can select the server in ESM, select the "Public Folder Referrals" property page, and then opt to use a customized list of public folder servers for referrals, as shown in Figure 7.43. This is known as a "forced referral." In all instances, whether you distribute public folders or access their content via referrals, system administrators can see the folders and replicas that exist in each administration group by browsing through the TLHs to find individual folders that seem interesting. They are then able to create a new replica on their server. The only way to prevent this behavior is to block administrative rights to the folder and deny access to everyone except a small group of users.

Figure 7.43: Selective public folder referrals.

The case for referrals is hard to argue in terms of user convenience, and this fact is borne out by experience. Most companies that have tried to centralize public folders have not persisted because of slow network access. The most obvious advantage is the fact that a single network-wide copy represents definitive data. This cannot be said of a replicated folder, because the possibility always exists that a change to the content has been made somewhere in the network and has not yet arrived on the local server. The concept of a single definitive source of information attracts many organizations, especially when that information is critical corporate information. You have to make a decision regarding whether your network is able to facilitate fast (or at least acceptable) access times to the information. If there are many slow links in the network, replication is usually a better solution.

7.13.3 Scheduling replication

The PFRA replicates public folder data according to whatever schedule you set on a Public Store. Each Public Store has its own schedule, and you can set a specific replication schedule on a folder, so it is possible to schedule on a "fit for purpose" basis. For example, you can schedule replication for a folder that holds policy documents that you do not change very often once a week at a time when the network is quiet. On the other hand, you probably want to replicate a folder that holds data used by a forms application every 15 minutes or less to ensure that users see up-to-date information across all replicas.

Figure 7.44: Public folder replication schedules.

Figure 7.44 illustrates both options. You can see the schedule for a Public Store on the right-hand side, while the schedule for a specific public folder is on the left. We can see that some of the fields are grayed out, which indicates that this Store is under the control of a system policy. You cannot change the replication interval, schedule, or size for this Store until you remove it from the list of Stores covered by the system policy. Note that you are able to define a precise Store schedule by changing the "always" interval to whatever value you like. In previous versions, this interval meant "every 15 minutes."

You can also adjust the size of replication messages, which is set to 1 MB in this instance. This does not mean that Exchange can only replicate items up to a maximum of 1 MB, since this would prevent replication of items such as a 5-MB PowerPoint presentation. Instead, the limit indicates the size of messages generated by the PFRA when it packs items together to send to another server. For example, if the limit is 300 KB and there are ten 90-KB messages for replication, the PFRA packs three of the 90-KB messages into a 270-KB message and sends it off, meaning that Exchange transfers four messages between servers (three of 270 KB and one of 90 KB). If a user then places a 400-KB item in the folder, the PFRA cannot pack this item into a 300-KB message, but replication still needs to occur, so the PFRA takes the item and sends it on intact to replication partners.

If you want to prevent users from adding very large files to public folders, use the "Maximum Item Size (KB)" field in the Limits property page. You can also apply limits and replication settings for Public Stores through a system policy, which is the best way to ensure that multiple servers use the same settings.

Exchange 2003 includes a new "Send Contents" ESM option (Figure 7.45) to allow an administrator to select a folder and instruct Exchange to replicate any changed content immediately. You can use this option to distribute urgent information by starting an immediate replication cycle to all replicas. Replication still occurs via messages, so nothing goes unless the messaging system works.

Figure 7.45: Send public folder contents.

7.13.4 When public folder replication happens

The following events cause public folder replication activity to occur:

• An administrator creates a new public folder in a public folder hierarchy.

• An administrator creates a new replica of an existing folder.

• A user adds some content to a public folder.

• The Store generates status requests.

• The Store generates backfill requests to complete a replica.

All the servers in an administrative group automatically share the same set of public folders and top-level folder hierarchy (TLH). You can host multiple replicas of folders on servers within an administrative group, but you should only do this if users are unable to connect to a single replica per administrative group. Each replica adds replication traffic and increases the complexity of public folder management.

7.13.5 How replication occurs

The PFRA takes care of monitoring changes made to public folders but only for folders where replicas exist. The Store maintains a list of servers that hold replicas, or instances, as a property of each folder. After users add or change content in a folder, the PFRA takes care of dispatching details of the changes to all of the other servers that hold replicas, using messages sent from the Public Store to the Public Store on the recipient servers.

In addition to the relatively simple task of sending updates to other Public Stores, the PFRA maintains historical information about the state of each message in each replicated folder. The Store uses a mechanism called Change Number Sets (CNS) for this purpose. Each folder has a unique set of change numbers, based on a GUID (global unique identifier, based on 64-bit hex strings). Conceptually you can think of the number set being incremented by 1 as each change is made to a folder (addition, modification, deletion). Thus, the first item added to a folder becomes change number 1, the second number 2, and so on. The CNS for the folder is now 1-2 (the actual values are more complicated). If someone now creates a replica, the Store sends the CNS in a status message to inform the Store on the receiving server that it must backfill its new replica with the content represented by CNS 1-2. The name of the server is included to make the CNS unique. Thus, you could think of the CNS as being something like:

EXCH-SRVR\PUBIS\0174345

The change number shows that this is change number 174,345 generated by the Public Store on the EXCH-SRVR server. Of course, real change numbers are in an encoded fashion that makes sense to computers, not humans, so this example is purely to illustrate the point. The PFRA maintains a list of all predecessor change numbers for a Public Store, meaning that the agent is able to recognize the most recent or current message.

The Store generates a status message containing the current CNS for each replicated folder daily and sends it to all servers that hold replicas. This message serves to prime the replication system and ensure that any servers that receive the message will check the folder replication status and request backfills for any missing data. The CNS is also included in every message that contains replicated content, a step that ensures that backfill will occur even if a server misses any status messages for some reason.

The simplest replication task involves new items. When a user adds a new item to a folder, the PFRA creates a new change order and sends it along with the content of the new item to all of the other servers that hold instances of the folder. The receiving servers check the incoming replication message to determine whether they have already received the content. If the checks pass, the local Public Store inserts the new item into its copy of the folder. Deletions follow a similar path, except that the PFRA only sends instructions to remove the items. Updates are slightly more complex, because the local Store must verify that the incoming change is for the same version or a later version of the message that it holds.

If permissions allow, all servers are entitled to modify items. The Store always applies modifications to local instances, so the local PFRA takes responsibility for informing the other servers that a change has occurred. When a modification message arrives to a Public Store, it replaces the original content, but only if the modification is more current than the existing message. The Store uses the change number on the message and the predecessor change list to determine whether it should apply the message. If the Store discovers that it has content that is more up-to-date than the content in the replication message, it realizes that a potential conflict exists, and a conflict resolution process begins. "Process" is too powerful a word here, because it implies that Exchange uses some form of artificial intelligence to resolve concurrent updates applied to the same content from multiple points. This is not the situation, because the process is manual. The users who attempt to update the content receive a conflict notification and copies of all the changes. They can proceed to resolve the conflict manually by reviewing all the changes and merging them together into an agreed-upon copy, or just take the option to apply their original change-which is what normally happens!

7.13.6 Monitoring the flow of replication

Replication should flow smoothly as long as messages pass between Exchange servers. The inability of users to access a folder is the most commonly reported problem, and the reason for this is usually one of the following: The user does not have the necessary permission to access a folder, or a local replica does not exist and a referral to a remote replica is not possible across a connector.

Insufficient permissions are the most common problem, but if not, replication might not be working. The easiest way to check if a problem exists in the messaging infrastructure is to send a message to a mailbox on the server that hosts the replica. Set a delivery receipt on the message so Exchange notifies you when the message reaches the server. If you get a delivery notification, you know that messages are flowing between the two servers and you can assume that Exchange can send and receive replication messages. You can use the Message Tracking Center to follow the path of the message, providing that administrators have enabled the message tracking on all servers along the message's path. However, if you receive a delivery notification, this step is not necessary unless you have another reason to track the progress of a message.

The next step is to turn up the diagnostics setting for the "MSExchange IS\Public" object and then examine the collected information. The normal diagnostics setting is "None," meaning that Exchange only records errors in the Application Event Log. You can set the various replication categories (such as "replication incoming messages") to "Medium" or "Maximum" to see how Exchange processes replication requests (Figure 7.46). Be warned that a large volume of events will accumulate quickly on servers that host busy public folders or servers that replicate content at short intervals.

Figure 7.46: Adjusting diagnostics for public folder replication.

Once you have increased the diagnostic level, you can add an item to the public folder to force replication to occur. Select the folder that the user cannot access and set its replication interval to "Always." Add some content to the folder and observe the information written by the Store in the event log.

Figure 7.47 illustrates two typical replication events as reported in the event log. The left-hand screen (event 3028) reports that the Store has processed an incoming replication message for a subtree in the Compaq Worldwide Functions folder. You can clearly see the minimum and maximum values of the CNS (1-2e2-4690CDA to 2e2-4690DED), which makes little sense to people. The message type is 0x2 (2), meaning that this message contains new folder information being replicated from this server to another server. In other words, a user has created a new folder under the Compaq Worldwide Functions folder. By contrast, the right-hand screen (event 3020) reports details of an outgoing replication message. The message type is 0x4 (4) and you can see the full path to the folder where someone added, changed, or deleted content. Again, the event reports details of the CNS.

Figure 7.47: Typical replication events.

Other valid message type codes are:

8: Backfill requests-a server is requesting some backfill data to complete its replica.

10: Status message-the server is reporting the CNS for one or more folders to other servers.

20: Status request-the server is looking for a replica of a folder to retrieve information or is reporting that it is still active.

Matching the diagnostic information collected in the event log with the knowledge you have of the public folder hierarchy and replication intervals provides invaluable background knowledge of how the PFRA works. This is a subject often ignored by system administrators, only to become a hot topic when things go wrong and everyone is wondering why replication is not working, or why too much replication activity is going on.

7.13.7 Backfilling public folders

Backfilling describes the process by which a server updates the content in a public folder replica with information that is missing for whatever reason. Backfilling also occurs when you create a new folder replica to populate the folder with content. System outages include hardware crashes, which may cause an administrator to restore a Public Store on a server. A restored database is often out-of-date in some respect, and may lack some content replicated from other servers since the server's last full backup. The Store usually recovers most of the missing content when it replays transaction logs to make the database consistent, but often some content was en route when the outage occurred. Therefore, when you restart the server, the Store checks incoming replication messages from other servers and then uses the change numbers in the messages to update its predecessor change list.

Examining the change numbers reveals if any gaps exist in the predecessor change list, and, if this is the case, the Store begins the process of filling the gaps, or backfill.

The Store begins by generating a backfill entry, which is literally a placeholder inserted into the database to indicate that some data is missing. It then proceeds to dispatch requests for assistance to two other servers (chosen at random) that also hold replicas of the folders that are missing information. The request specifies what the missing content is and requests the receiving server to generate a message containing the content and send it back to the requesting server.

Exchange never executes backfill messages immediately after receiving a response from a remote server. Instead, it keeps the messages in a queue for up to two hours to await the arrival of messages containing the original content that was marked as missing. If the waiting period elapses, it sends a message containing the backfill request to the store on the folder's home server. When the home server receives the backfill request, the Store examines its detail to determine what content is required, as defined by the CNS. The Store then generates one or more messages with the missing data and sends them off. The Store also sends a status message that contains details of the current CNS from the home server to inform the replica what the current situation is. The Store continues to make backfill requests until the CNS of the replica is the same as the CNS on the home folder.

With Exchange 2003, you can set the preferred server for backfilling public folder content by updating the AD with the GUID of the preferred server in the msExchPreferredBackfillSource attribute on the target Exchange servers' Public Store objects. Alternatively, you can update the registry, again using the GUID. Neither approach is exactly people friendly, since it is all too easy to make a mistake when you type in a GUID. Microsoft PSS has scripts to help you, so if you ever need to force backfill behavior in this way, contact PSS and ask them to help.

7.13.8 Replicating public folders with Exchange 5.5

You have to create a public folder connection agreement with the ADC before you can replicate public folders between Exchange 5.5 and Exchange 2000/2003 servers. A public folder CA replicates details of the public folders so that each type of server knows about the information held on the other. For example, the CA creates entries for Exchange 5.5 public folders in the Microsoft Exchange System Objects OU of the AD (Figure 7.48). Because public folders are "owned" by sites in an Exchange 5.5 organization, you need a separate CA for every site to create a full set of public folders in the AD. Public folder CAs are always two-way to ensure that public folder information is consistent on both sides, and, unlike user CAs (which replicate information about users, contacts, and groups), you cannot change the source and target destinations, since these are predefined.

Figure 7.48: Public folders in the AD.

7.13.9 Erasing zombies

The upgrade from Exchange 5.5 to Exchange 2000/2003 incorporates a fundamental change in security, as Windows ACLs replace the old Exchange-specific public folder permissions maintained in the DS. Permissions form part of the attributes of a folder, and the Store automatically converts the old format to the new as you upgrade servers. However, occasional inconsistencies can creep into the process (typically a failure to convert old Exchange permissions to Windows ACLs), which can lead to user problems, such as the inability to see public folders or bad performance when browsing the public folder hierarchy. Even after you complete the upgrade from Exchange 5.5, you can still experience problems if public folder ACLs contain lingering Exchange 5.5 permissions that, for one reason or another, failed to convert in the past. These attributes are zombie permissions, because they can never go anywhere, since there are no Exchange 5.5 servers to resolve the old format permissions.

If you suspect that you have a problem with zombie permissions, perhaps because users report that they cannot see folders, you can set a registry value to instruct the Store to ignore zombie Exchange 5.5 permissions always. To do this, open the registry and then navigate to the following key:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ ParametersSystem\

Then, create a new DWORD value called "Ignore zombie users" and set it to 1. While it is nice to eliminate zombies, you should not set this parameter unless you have eliminated any other possible cause for the reported problem. The parameter is valid on Exchange 2000 SP3 and Exchange 2003 servers. See Microsoft Knowledge Base article 327167 for more information.

7.13.10 Problems with public folder replication

The problems with public folder replication are many and varied. First, you have to decide how many replicas are required. Next, you have to distribute the replicas throughout the organization in such a way that you do not flood servers with replication traffic but still maintain fast access for users. Third, you have to decide how to channel user access. In Exchange 5.5, the site model determines access, and Exchange uses a simple preference algorithm that favors server, location, site, and then a remote replica. Public folder affinity defines how Exchange selects replicas on different servers. In Exchange 2000/2003, routing groups supersede the site model and referrals to remote replicas via connectors replace affinity. Planning referrals or affinity can get quite complex in a large, distributed organization, and it is probably one of the least understood administrative concepts for Exchange.

Assuming that you manage to place a sufficient number of replicas out in the organization, have no replication issues, and users can always get fast access to folder content, the next issue that looms is replication clashes. Exchange has no way to check documents for exclusive access, and public folders follow a multimaster replication model where all masters share equal status in terms of the definitive copy of an item. Thus, you can get into a situation where two or more users decide to edit the same item concurrently, each connecting to a different replica. The problem does not occur if there is only one replica, because the Store can then prevent two users from attempting concurrent edits. Now let us assume that the users finish their work and commit their changes back into the public folder. The Store recognizes that a change has occurred and replicates update information to the folder replication partners, but at the same time, other servers take the same action, which leaves the Store in a "replication clash" scenario when the competing changes arrive. Exchange does not possess artificial intelligence or insight into the minds of the respective authors, so it throws its hands up in disgust and lets the people sort out the problem. Naturally, any user believes that his or her change is absolutely the most important information, so the user accepts the update and discards the others-a scenario that is likely to occur on other servers.

In early versions of Exchange, it was possible for administrators to browse the public folder hierarchy, find folders that seemed to hold interesting information, and instruct Exchange to create a new local replica on their server. Exchange 5.5 allowed administrators to eliminate this practice by setting a property on public folders to limit administrative access to the home site. In other words, if you set the property, remote administrators could not then decide that they would like to set up a new replica. Practical experience demonstrated that many administrators missed this subtle but important point and replica numbers continued to expand in most deployments.

The migration from Exchange 5.5 to Exchange 2000/2003 is an excellent opportunity to conduct a full review of public folders and replicas. At the same time, you can look at each folder to decide whether its original purpose is still valid, and you should keep the folder or delete it to help clean up the public folder hierarchy. While you check each folder, take the time to review who the folder owner is, whether he or she still wants to be the folder owner (some people forget they have ownership if they take up new responsibilities), and the other people who access the folder. It is best practice to use distribution lists to control access to public folders, since this reduces the number of entries in the access control list, and it is easier to grant or deny access to folders through a simple edit of a distribution list. When you move public folders from Exchange 5.5 to Exchange 2000, the Store upgrades the access control list from Exchange-specific permissions to Windows 2000 permissions, and cleans up the access control lists by removing users who no longer need access to make the migration less complex.

7.13.11 Long-term options for public folders

When public folders first appeared, they offered some significant advances over network shares as document repositories and included such things as electronic forms, document routing, workflow, and so on. After nearly a decade, public folders have aged badly, and Microsoft has not succeeded in developing their capabilities to a point where every Exchange installation can point to a successful and useful deployment. The attempt to broaden acceptance through multiple top-level hierarchies has foundered through excessive complexity and the lack of MAPI support, plus the simple fact that public folders are just too hard to manage in large deployments. It was always doubtful that it was a good idea to add extra hierarchies without a suite of management tools to control and rationalize existing public folders and so it has proved to be in reality. Finally, public folders are hard to search, so looking for a specific item can be like looking for the proverbial needle in a very large haystack.

Perhaps Microsoft never really believed in public folders or maybe it lost interest after the original vision faded. It is also true that other imperatives took engineering attention as Microsoft fought a bitter email war against Lotus. Indeed, you can argue that Microsoft lost complete interest in public folders as soon as it could claim that it had beaten Lotus for corporate messaging prominence, since public folders have seen very little progress since.

However, I think that the real reason is that Microsoft has better technology that it can sell outside Exchange. This technology features document versioning, check-in and check-out facilities, basic approval routing, a good search engine, the ability to index public folders (backward compatibility), browser and Windows Explorer interfaces, good integration with Microsoft Office applications, and it's easy to deploy. While SharePoint Portal Server (SPS) does not support replication-possibly the only real advantage that public folders now hold-you can argue that the advantages of replication are overvalued, given that most companies have sufficient bandwidth to allow users to access a single definitive source of information and do so by deploying Web sites all the time. In addition, the management problems that replication can bring make the prospect of deploying multiple replicas around an organization less attractive.

On the other hand, public folders are free and deploying SPS incurs additional cost, since you must license every client. You also have to deploy the SPS client if you want to access documents through Windows Explorer and Office applications, and there is the small matter of additional hardware, because you cannot deploy Exchange and SPS on the same server, plus the cost of different antivirus and backup tools, and so on. SPS is, therefore, no silver bullet to address all the inadequacies found in public folders, but it is an option for organizations that want to deploy lightweight document management or department-level portals. With some care in planning, SPS is capable of serving very large organizations too, although its management tools are still raw.

The future of public folders is unclear. You cannot anticipate a massive investment in engineering time from Microsoft to make public folders a comprehensive platform for document-centric applications, and short of a complete redesign, it is difficult to see how they will progress. For this reason, it is best to treat public folders as an ad-hoc repository for documents and messages and look to other solutions like SharePoint Portal Server for anything more sophisticated.

---