Lesson 1: Public Folder Strategies | MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration

Both single and multiple public folder instances have advantages and disadvantages that you need to take into consideration when planning your public folder strategy. Exchange 2000 Server is flexible and allows you to create or eliminate public folder replicas at any time. It is good practice to reassess your approach to public folder replication periodically.

This lesson covers the major aspects of public folder strategies. It points out the various advantages and disadvantages of single and multiple public folder instances and discusses advantages and disadvantages of dedicated server configurations.

At the end of this lesson, you will be able to:

Describe the advantages and disadvantages of single public folder copies.
Describe the advantages and disadvantages of one or more replicas.
Decide whether to configure dedicated public folder and mailbox servers.

Estimated time to complete this lesson: 45 minutes

Stand-Alone Public Folders

Stand-alone public folders are the default configuration, but they may or may not be ideal for your purposes. In other words, public folders are not replicated to other servers without administrative intervention.

Advantages of Stand-Alone Public Folders

A single public folder consumes disk space on one server only; additional disk space for redundant folder copies is not required. Users connect to the central server to work with the public folder. Because there is no replication delay, changes to the contents are seen immediately by users. The single public folder model works best in small environments with local area network (LAN) connections, where redundancy is not critical.

Disadvantages of Stand-Alone Public Folders

As mentioned, stand-alone public folders do not provide fault tolerance. To implement fault tolerance, you must create redundant public folder instances. Furthermore, it is impossible to provide load balancing. All users have to access one particular server to open a public folder, so this server can become a very busy machine. Likewise, users can access public folders only if LAN-like connections exist. If a wide area network (WAN) connection connects routing groups, access to stand-alone public folders in remote routing groups might be slow or impossible (see Exercise 3 of Chapter 17, "Public Folder Management").

The following are notable features of stand-alone public folders:

Public folder maintenance is centralized because only one public store is affected.
Underlying network topology determines quality of public folder access.
No additional disk space on further servers is required.
There is no overhead or latency due to public folder replication.
Bottlenecks in public folder access are possible if the public folder server is overtaxed.
Public folders are not available during server maintenance.

Replicated Public Folders

Public folders are easy to clone. You can have the same public folder on any of your Exchange 2000 servers, but this would consume a lot of disk space. Public folder replication ensures that the content of all instances of the same public folder is kept up to date.

Advantages of One or More Replicas

The main advantage of multiple public folder instances is increased fault tolerance. If one of the servers becomes unavailable, your users can still access the contents. If both servers are available, multiple instances can provide load balancing. Users can work with both replicas at the same time. Through public folder replication, you can address network topology issues. If direct client access is not suitable, create a second replica in an accessible location (see Figure 18.1).

You may want to replicate at least one instance of each public folder to all routing groups, even if direct access over WAN connections is supported, because it can speed up folder access. Furthermore, client traffic over the WAN is eliminated, which benefits other processes, such as message transfer between routing groups. Instead of having multiple users accessing the same information, the information is transferred once using public folder replication messages. You can also schedule the public folder replication and configure other parameters based on routing group connectors, as explained in Chapter 16, "Message Routing Administration."

The following are some features of replicated public folders:

A replica of a public folder can be kept available in all locations for local access.
Client access over WAN connections can be eliminated.

Figure 18.1 Enabling local access to a public folder
Fault tolerance between multiple servers is available.
Load balancing between multiple servers is possible.
Public folder replication can be scheduled.
New items posted in a public folder instance are not immediately available in all other locations due to public folder replication latency.
Public folder replication latency increases the chance of conflicts due to concurrent changes of existing items.
Public folder replication must be configured manually, but new subfolders inherit the settings of their parent folders.
Public folder replication relies on e-mail messages and increases message traffic.

Public Folder Instances Between Organizations

True public folder replication is only supported within a single organization. To replicate public folder content between separate organizations, the InterOrg Replication utility should be used, which is available on the Exchange 2000 Server CD in the \Support\Exchsync\i386 directory. Network News Transfer Protocol (NNTP) newsfeeds might also be an option for replication. However, NNTP relies on the concept of articles and does not provide the means to replicate other objects directly, such as Microsoft Word documents. The server on the receiving side would end up with message items that contain Word documents as attachments. Support for NNTP was covered in Chapter 11, "Internet-Based Client Access."

The InterOrg Replication utility replicates items in Exchange format. You need to run this utility on a dedicated Microsoft Windows 2000 workstation, which typically belongs to the Windows 2000 domain of the publishing Exchange 2000 server. In essence, this utility behaves like a user connecting to multiple Exchange 2000 servers. In fact, it relies on Microsoft Outlook, and you need to configure mailboxes for it on the servers that you want to connect to. A replication configuration tool (EXSCFG.EXE), which is part of the InterOrg Replication utility, facilitates the configuration task. Another component, the actual replication service (EXSSRV.EXE), is responsible for content replication. You can read more about the InterOrg Replication utility in the Exchange 2000 Server Online Help.

NOTE
Using the InterOrg Replication utility, it is possible to replicate free/busy information. To map free/busy information to the correct accounts in the destination domain, create corresponding mail-enabled contacts. Make sure that the Simple Mail Transfer Protocol (SMTP) address of the original mailbox-enabled user account matches the underlying e-mail address of the mail-enabled contact object. You can read more about mailbox- and mail-enabled recipient objects in Chapter 13, "Creating and Managing Recipients."

Configuring Dedicated Public Folder Servers

On dedicated public folder servers, mailbox stores have been removed, as demonstrated in Exercise 1 of Chapter 14, "Managing Server Configuration." The separation of server tasks allows you to design hardware resources explicitly and therefore more precisely. All users in the organization can potentially access the public folder server. Therefore, you should optimize the hardware for fast network input/output (I/O). Optimizing storage performance using a redundant array of independent disks (RAID) is the best way to do this.

Because a dedicated public server can take over responsibility of all existing public folders, the response time of the remaining servers will improve with a reduced load. For fault-tolerant implementations and load balancing, you can configure two or more dedicated servers and replicate public folders between them (see Figure 18.2).

click to view at full size

Figure 18.2 Accessing a public folder on a dedicated public folder server

Disadvantages of Dedicated Mailbox Servers

Similar to dedicated public folder servers, you may want to configure dedicated mailbox servers to avoid the accidental creation of top-level public folders on those machines. Although this is possible, you should refrain from it because of significant disadvantages. You would have to delete the public store associated with the default Messaging Application Programming Interface (MAPI)-based hierarchy from the mailbox servers. A default public store on another server must then be specified for all local mailbox stores to provide access to the MAPI-based public folder hierarchy (see Exercise 1 of Chapter 14, "Managing Server Configuration"). Keep in mind that neither fault tolerance nor load balancing is provided for hierarchy access. Hence, if the server that holds the default public store shuts down, users with mailboxes on corresponding mailbox servers will not be able to work with public folders. They can't navigate through the hierarchy any longer, which puts an effective end to public folder access, regardless of the number of public folder servers that have the contents available.

To put it plainly, it is not advisable to delete the public store associated with the MAPI-based hierarchy from any server. Use Exchange System Manager to place all top-level folders on a dedicated public folder server and configure their replication if desired. Revoke permissions to create top-level folders, but grant your users the rights to set up subfolders. Subfolders will be placed where the parent folder is located, and they inherit the parent's configuration, including replication settings. In addition, you always have the option to propagate configuration changes to existing subfolders, as illustrated in Chapter 17, "Public Folder Management."