Configuring Public Folders

Public folders have received a lot of attention for the last two releases of Exchange Server. The rumors of the removal of public folders in Exchange Server 2007 caused an uproar in the messaging community. The fact is that public folders are still supported in Exchange Server 2007 as well as Exchange 2010, and there is good reason for the feature's continued existence as it still fills a need that in some cases is not easily solved by other solutions such as Microsoft Office SharePoint Server or InfoPath. As Table-6 shows, in a number of scenarios public folders still provide a viable solution.

Scenario 		     Using Public     New to Public Folders ?
                                 Folders?
Calendar Sharing 	     No need to move 	  Use either
Contact Sharing 	     No need to move 	  Use either
Custom Applications 	     Consider SharePoint  Consider SharePoint
Discussion Forum 	     No need to move 	  Use either
Distribution Group Archive   No need to move 	  Use either
Document Sharing 	     Consider SharePoint  Deploy SharePoint
Organizational Forms 	     No need to move 	  Use InfoPath

One of the current solutions that SharePoint Server does not fill is that of a multiple-master document share, where document repositories can be replicated to multiple sites to provide access to data at remote sites.

In Exchange Server 2010 public folders support and features have not changed appreciably since Exchange Server 2007 SP1. Despite being a great solution for many client use cases, public folders still remain complex to manage in large environments and complex to recover from when problems arise without third-party tools. One of the only improvements made in Exchange Server 2010 with regard to public folders is that they can now be placed on multiple servers that are in a high-availability configuration, whereas before they were only supported on a single high-availability-configured server and its copy. This may now reduce the number of servers that are deployed because a dedicated public folder server is no longer required.

The choice to use public folders most likely means that either the application requirements are not met by another technology or the company use of public folders is so innate that the migration will take a number of years to complete. It is still important to bear in mind that public folders as they exist today will eventually cease to exist. A new large deployment of public folders should be very carefully scrutinized as to whether it is the best solution. To understand where public folder replicas need to be placed, it is important to remember how clients find and access replicas. When a user connects with Outlook or Outlook Web App to a public folder the following occurs:

1. The default public folder database for the user's account is always the initial target for all requests. If there is a replica available in that public folder, Exchange Server directs the client to this database for the public folder contents.
2. If a replica is not in the user's default public folder database, Exchange Server redirects the client to the least-cost Active Directory site that stores the public folder database. The Active Directory site must include a computer that is running Exchange Server 2010 or Exchange Server 2007.
3. If no computer running Exchange Server 2010 or Exchange Server 2007 in the local Active Directory site has a replica of the public folder, Exchange Server redirects the client to the Active Directory site with the lowest-cost site link that does have a copy of the public folder contents.
4. If no computer running Exchange Server 2010 or Exchange Server 2007 has a copy of the public folder contents, Exchange Server redirects the client to a computer running Exchange Server 2003 that has a replica of the public folder contents, using the cost assigned to the routing group connector(s). This behavior, however, is not the default- to allow public folder referrals across the routing group connector the properties of the routing group connector must be modified.
5. If no public folder replica exists on the local Active Directory site, a remote Active Directory site, or on a computer running Exchange Server 2003, the client cannot access the contents of the requested public folder.

Configuring public folder replicas requires that a detailed Active Directory site topology is understood as well as the methods and locations that the public folder data will be accessed from. A number of methods are chosen for creating replicas for public folders. The primary goal is to keep as few replicas for each folder while maintaining the appropriate access and redundancy.