Programming4us
         
 
 
Applications Server

Exchange Server 2010 Mailbox Services Configuration (part 5) - Configuring Public Folders

10/17/2010 5:17:08 PM

8. 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 2 shows, in a number of scenarios public folders still provide a viable solution.

Table 2. Deciding to Deploy Public Folders
SCENARIOUSING PUBLIC FOLDERS?NEW TO PUBLIC FOLDERS?
Calendar SharingNo need to moveUse either
Contact SharingNo need to moveUse either
Custom ApplicationsConsider SharePointConsider SharePoint
Discussion ForumNo need to moveUse either
Distribution Group ArchiveNo need to moveUse either
Document SharingConsider SharePointDeploy SharePoint
Organizational FormsNo need to moveUse 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.

Figure 2 shows how Exchange Server uses Active Directory sites to provide clients with the closest replica of a public folder for a public folder that is not available in the user's default public folder database.

Figure 2. Connecting to the closest public folder replica


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.

8.1. Configuring Public Folders for Site Redundancy

As an example, let's look at how Fabrikam 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: 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.
8.2. 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.
8.3. 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.

Other -----------------
- Exchange Server 2007: Monitor Your Exchange Environment (part 4) - Microsoft Operations Manager (MOM 2005)
- Exchange Server 2007: Monitor Your Exchange Environment (part 3) - Performance Troubleshooter
- Exchange Server 2007: Monitor Your Exchange Environment (part 2)
- Exchange Server 2007: Monitor Your Exchange Environment (part 1)
- Use the Exchange 2007 Toolbox to Troubleshoot
 
 
Most View
- BizTalk Server 2009 : Getting results from asynchronous invocations (part 2)
- Exchange Server 2007: Monitor Your Exchange Environment (part 1)
- jQuery 1.3 : Sorting and paging (part 1) - Server-side sorting
- Windows 7: Setting Up a Peer-to-Peer Network (part 1) - Changing the Computer and Workgroup Name
- SharePoint 2010 : SQL Server Reporting Services 2008 (part 2) - Understanding the Architecture of SQL Server Reporting Services 2008
- iPhone Programming : Connecting to the Network - Detecting Network Status
- Backing Up with the dump Utility (part 1) - Syntax of the dump Command & The Options to the dump Command
- SOA with .NET and Windows Azure : WCF Discovery (part 1) - Discovery Modes
- Windows Server 2008 : Configuring Windows Media Services (part 13) - Configuring Caching Settings
- Windows 7 : Customizing the Start Menu’s Power Button
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS