Public folder strategies depend to a large extent on the purpose and meaning of workgroup and workflow solutions to your business processes. For instance, if your organization plans to utilize public folders merely for simple discussions among users, it would be acceptable to leave the environment unstructured and allow all users to create public folders at all levels. In a network with fast and reliable connections, you do not have to configure anything extra for access to public folders to work. However, if you are planning to implement mission-critical solutions based on public folders, sophisticated configurations are required to achieve the desired performance and reliability. In any case, it is advisable to put some thought into the general configuration of public folder structures to be prepared for groupware.
This lesson discusses several issues related to public folder resources. You will read about the purpose of hierarchies and the replication of public folder contents between servers. You will also learn about good reasons why you should restrict the right to create top-level folders in a hierarchy to a small group of administrators. The information from this lesson allows you to configure public folder structures according to the groupware requirements of your organization.
A public folder is a repository for message items and other objects (such as multimedia clips, text documents, and spreadsheets) that is stored in a public store database of the Information Store service and shared between the users of an Exchange 2000 organization. Public folders are the foundation for workgroup and workflow applications, as well as information and knowledge management solutions. Discussion forums and document management systems are good examples of public folder applications. It is also possible to create special Microsoft Outlook public folders for Calendar, Task, Journal, and Contacts items to provide team planners, activity-tracking solutions, and public contact databases, as explained in Chapter 1, "Introduction to Microsoft Exchange 2000 Server." Furthermore, you can mail-enable public folders to include them in the global address list (GAL) as ordinary recipient objects.
A variety of messaging clients provide you with access to public folders, including Outlook 2000, Internet mail clients, newsreaders, and Web browsers. Based on the WSS and Exchange Installable File System (ExIFS), standard Win32 programs, such as Microsoft Windows Explorer or Microsoft Office applications, can also open public folders as directories on a hard disk.
Public folder access relies on two elements: the public folder hierarchy and the public folder contents. The hierarchy represents the tree of public folders (top-level folders can contain subfolders, those can contain other subfolders, and so on). The contents consist of the actual items stored in the folders. The hierarchy helps users navigate to the desired folders, which they need to open to access the contents (Figure 5.18).
Figure 5.18 - Hierarchy and contents of public folders
Exchange 2000 Server supports multiple public folder hierarchies, which gives you flexible control over workgroup and workflow solutions. It is important to note that every hierarchy must be associated with a separate public store database. On a single server, this means that a particular hierarchy can only be associated with one public store and that every public store must have its own hierarchy. Public stores on different servers, however, may refer to the same hierarchy, in which case the hierarchy is automatically replicated between the servers.
The following two types of hierarchies can exist on an Exchange 2000 server:
Public folder hierarchies belong to the administrative group in which they are created, even though they may be replicated to public stores on servers in other administrative groups. The MAPI-based hierarchy, for instance, belongs to the First Administrative Group, by default. It is possible to create a dedicated administrative group for all public folder hierarchies, create a public folders container underneath it, and move all hierarchies into this container. You can then grant dedicated public folder administrators access to this administrative unit in the Exchange 2000 organization. It is important to note that this administrative group does not need to hold any servers. It is possible to move public folder hierarchies between administrative groups in both mixed and native modes.
When you create top-level public folders in Outlook 2000, bear in mind that these folders are placed on your default public store server. This is usually the server that holds your mailbox (Figure 5.19). If you plan to implement dedicated public folder servers, it is a good idea to create top-level folders in Exchange System Manager only. Exchange System Manager allows you to connect to the desired server explicitly. Right-click the desired hierarchy object, and select Connect To to select the server. You can also create the top-level folders directly on the server using Windows Explorer. Your users will create subfolders automatically on the same server as the parent folder because subfolders inherit the parent folder’s configuration automatically.
Note
Figure 5.19 - Creating top-level folders on a dedicated public folder server
The right to create top-level folders (folders at the top of the All Public Folders tree) should be restricted to a small group of administrators to maintain control over the creation of the resources. This restriction allows you to organize your organization’s public forums based on geographical location, business unit, or whatever criterion suits you. For every top-level folder you can grant permissions to an appropriate department, team, or other group of users to manage the creation, content, and permissions of subfolders.
It is not a trivial task to prevent everyone from creating top-level folders. One option is to right-click the desired hierarchy object in Exchange System Manager, select Properties, switch to the Security tab, and clear the Allow Inheritable Permissions From Parent To Propagate To This Object check box. A Security dialog box appears, asking you whether you want to copy previously inherited permissions. It is a good idea to click Copy; otherwise, you have to configure all security settings manually. After that, from the Name list, select the Everyone account, and clear the Create Top Level Folder check box. The disadvantage of this approach is that from this point forward, changes to permissions delegated at the organization or administrative group level are no longer inherited.
Perhaps a better way is to enable the Security tab for all objects in Exchange System Manager using the ShowSecurityPage Registry value, as explained earlier in this chapter. You can then right-click the organization object, select Properties, switch to the Security tab, select the Everyone account, and then directly clear the Create Top Level Folder check box. This time, the permission inheritance remains intact. However, keep in mind that the changes will affect all public folder hierarchies in all administrative groups. If you want to allow your users to create top-level folders in a particular hierarchy, you have to grant their accounts the Create Top Level Folder right on the hierarchy explicitly.
Note
The Information Store service, together with the Microsoft Search service of Windows 2000 Server, makes it possible to index the content of public folders and provide your users with the ability to locate Microsoft Office documents and message attachments through full-text searches. It is the Search service that maintains the full-text catalogs and indexes, which it automatically populates with significant keywords from messages, documents, and attachments. With content indexing enabled, the Information Store passes full-text searches over to the Search service, which returns those entries from the index that meet the full-text search criteria (Figure 5.20). The search engine of the Information Store can then construct the query result and return it to the user. Index-based searches can measurably increase the performance and speed with which searches are performed. You can enable full-text indexing via server policies or for public stores individually.
Figure 5.20 - Full-text searches in Outlook 2000
Note
To work with the actual items in a public folder, you must access the contents. Your client program sends an open request to your home server. If the server has the contents, you gain access. Otherwise, the server returns a referral list to your client indicating those servers that have the contents available. Based on the information from this list, the client connects to another server in the organization to provide you with access. If all target servers are inaccessible for some reason, you receive an error message that the folder content could not be located (Figure 5.21).
Figure 5.21 - Unable to access the public folder contents in Outlook 2000
Note
The routing group defines the boundary of permanent and reliable network connections. Within a routing group it should always be possible to access all servers directly. Hence, users can always work with local public folders. Between routing groups, however, the RGC configuration determines whether access to other servers is allowed. Every RGC provides a Do Not Allow Public Folder Referrals setting, which, if enabled, denies public folder access across the routing group boundary. The cost value of the connector establishes the public folder affinity. If multiple routing groups exist, the lowest cost determines the most preferred routing group in which to look for the folder contents. Keep in mind that public folder referrals are transitive. If access is allowed between routing Group A and routing Group B, and between routing Groups B and C, then it is implicitly allowed between Groups A and C as well.
Note
Public folder replication allows you to distribute multiple copies of public folders to different Exchange 2000 servers and keep them synchronized. Multiple public folder instances can share the workload and increase fault tolerance through redundancy. Public folder replication also allows you to address network topology issues. If a direct connection to a remote public folder server is not possible, create a second replica in an accessible location and your users can collaborate (Figure 5.22). Replicating at least one instance of each public folder to all routing groups can help to speed up folder access because client connections over WAN links can be avoided. By default, a newly created top-level public folder is not replicated to any other server, which means that replication requires an explicit administrative step.
Figure 5.22 - Access to a local public folder replica.
Note
In the Enterprise edition of Exchange 2000 Server, public folder stores have no size limit (the stores of the Standard edition are limited to 16 GB). To control the size of a public store, configure storage limits on a per-folder basis. You can also apply storage quotas for individual public stores or within a public store policy for multiple stores, but it is advisable to configure size limits for public folders individually according to their purposes. You can likewise specify age limits, which determine how long a public folder retains items before deleting them automatically. Age limits configured at the public folder level define a common item lifetime for all replicas. To specify age limits per server, you have to specify the settings at each particular public store or in a server policy.
Public folder strategies rely primarily on one basic element—the top-level folder. All folders created within a top-level folder inherit important configuration settings from their parent folder, including their home server and replication settings. To put your public folder strategy into effect, you need to control the creation of top-level folders. Only a small group of administrators should have this right. Top-level folders should be created on an appropriate public server and can be replicated across the entire organization.
A central question in every public folder strategy is whether to replicate public folders between multiple servers. Multiple replicas can help you increase system performance through load balancing. They also increase fault tolerance. If a public server goes down for any reason, the contents are still available on another server. However, there is a trade-off: Replication itself creates network traffic, the replicated content consumes hard disk space, and replication delays increase the chance of conflicts that occur when two users on different replicas modify the same item at the same time. Table 5.2 summarizes the advantages and disadvantages of single-instance and replicated public folders.
Note
Table 5.2 Advantages and Disadvantages of Single-Instance and Replicated Public Folders
Single-Instance Public Folder | Replicated Public Folder | |
---|---|---|
Advantages | | |
Disadvantages | | |
Adventure Works is planning to implement workgroup and workflow solutions, but to stay within budget, John Y. Chen decided to install no dedicated public folder servers. The company’s server infrastructure is shown in Figure 5.15.
"Our four subsidiaries operate very independently and will develop their own workgroup solutions," said Chen. "We might implement global discussion forums, but only on a very simple level. Access to forums in remote locations will be infrequent, and our VPNs are fast enough to support direct access to these forums. For this reason, we will not block public folder access between routing groups and will replicate mission-critical folders only between the servers in the local routing groups. This arrangement implies that our mailbox and bridgehead servers will assume the responsibilities of public servers. Should we discover a performance bottleneck in the future, we will implement dedicated public folder servers. In our organization, only enterprise administrators will be allowed to create top-level folders. The departments and business units will have to request top-level folders in a formal way."
In this activity, you will develop a public folder strategy for Consolidated Messenger and Litware, Inc. Both companies’ server infrastructures were introduced in Lesson 3.
Tip
Consolidated Messenger does not plan to implement workgroup or workflow applications in the foreseeable future. "At Consolidated Messenger, we focus on messaging. The company is missing the skills and budget to develop sophisticated workgroup solutions. For the time being we would like to prevent everybody from working with public folders. Yet, as you may recall, our policies do not apply to the Video department. Again, political reasons demand that we allow the Video department full access to all features of Exchange 2000 Server. That’s why we implemented a separate administrative group," said Gregory J. Erickson, Senior IT Administrator.
It is your task to develop an appropriate public folder strategy for Consolidated Messenger.
Litware, Inc. plans to implement one administrative group with two routing groups for their sites in Los Angeles and Washington, DC. The company is considering implementation of workgroup applications, but not as part of the current project. "We will plan our public server infrastructure at a later time," said Nikki McCormick. "However, we want to provide a public folder structure for our project documentation, and we would like to avoid a situation where our users create proliferating folder structures. Implementing public folders at a later time does not mean we want to give up control over their arrangement."
It is your task to develop an appropriate public folder strategy for Litware, Inc.
A public folder is a repository for message items and other objects, such as multimedia clips, text documents, and spreadsheets. Because public folders are shared between the users in an Exchange 2000 organization, they are the foundation for workgroup and workflow applications.
When a user creates a top-level public folder in Outlook 2000, the folder is placed on the user’s default public store server. This may not be the server where you actually want to store public folders, and the configuration of the top-level folder, such as access permissions, may not follow organizational standards and conventions. Without restricting the right to create top-level folders to a small group of administrators, public folder hierarchies can quickly get out of hand.
General public folder strategies rely primarily on the controlled configuration of top-level public folders. All folders created underneath them will inherit their configuration parameters, including the replication configuration, permissions, age limits, and other settings. For every structure of public folders and subfolders, you need to decide whether to replicate them between servers or to provide them as single instances. Both approaches have advantages and disadvantages. Single-instance public folders do not consume additional disk space on other servers, but it may not be possible to access them from all locations in the corporate network. Public folder replication can solve this problem, but at the expense of increased replication traffic. The situation and the importance of the public folder dictate whether replication should be configured. Implementing multiple replicas can increase system performance due to load balancing and is a means to providing fault tolerance.