Configuring Public Folders for Site Redundancy

As an example, let's look at how Michael uses public folders. A special project team located in the Fresno office uses a set of public folders to store information about their project. Because all of the users are located locally, there is no need to create a replica of the project folders offsite. However, to ensure that data is not lost in the case of a local server failure, at least one offsite replica should be created.

Note: Note Often, especially when users are allowed to create public folders, replicas are not created when a new folder is created. This leaves database backups a primary recovery point for data in these public folders in case of a server failure. Create and schedule an Exchange Management Shell script to periodically report on any public folders that only have one replica.

Configuring Public Folders for Distributed Access

Another example of how public folders can be used can be seen at Litware. Rather than employing SharePoint at this time, the HR department uses a public folder to distribute documentation to all employees for review. This documentation does not change often; however, it is used by all employees on a regular basis. In this case a replica of the public folder should be created at each location so that employees have quick access to these files.

Note: Creating a large number of replicas will increase the amount of data that needs to be replicated to each server. This may affect the available bandwidth between sites. Care should also be taken when adding replicas so as not to add too many at a single time, which will reduce or eliminate the bandwidth required to transfer more important messages or other critical business functions.

Designing Public Folder Deployments

In environments where public folders are heavily used, it is a best practice to deploy dedicated public folder servers. This allows for dedicating CPU, memory, and disk resources to isolated server functions, reducing the likelihood of resource contention.

It is also beneficial to have fewer larger public folder databases, rather than having smaller public folder databases. This scales well and is more easily managed and monitored than having several smaller public folder databases. This also reduces the amount of replication traffic that must occur. As with many best practices, it still requires that adjustments be made to fit each environment. As the public folder configuration is designed, the number of databases needed to be deployed must be balanced by the cost of replication traffic and against the costs of management complexity, database backup, maintenance, and restore times.

Another factor to consider is the hierarchy of the public folders. As a general rule, because of how replication is structured it is best to have more nested folders rather than having more folders at the root of the hierarchy. When designing the hierarchy it is also important to consider the permissions that will be granted on the folders. The goal should be to simplify administration and reduce complexity as much as possible when assigning permissions. It is good to have the folders that will have the least restrictive permissions toward the top of the hierarchy, with the folders that require more restrictive permissions to the bottom. Often enterprises will create root folders for each business unit or region and allow departments and project folders to be created below the root folders. However, it is best not to have more than 250 subfolders in each folder.