Lesson 4: Public Folder Access Strategies

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.

After this lesson, you will be able to

  • Describe the purpose of public folders and the difference between public folder hierarchies and contents
  • Explain why and how to restrict the creation of top-level folders
  • Develop a general public folder strategy for an Exchange 2000 organization

Estimated time to complete this lesson: 60 minutes

Public Folders in an Exchange 2000 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.

Public Folder Clients

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 Hierarchies

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:

  • Default hierarchy This is the only hierarchy that MAPI-based clients can access. It is therefore also called the MAPI-based hierarchy. Public folders in this hierarchy are available to users of Outlook 2000, as well as Internet clients, Web browsers, and Windows applications. The default hierarchy is created automatically on each server and replicated to all public folder servers across the organization. Every user can examine the list of public folders, even though the content might not be accessible.
  • Alternate hierarchy This hierarchy is only available to Internet clients, Web browsers, and Windows applications. It is therefore also called the general-purpose hierarchy. Outlook 2000 users are unable to access these public folder trees. You can use Exchange System Manager to create them and associate them with a public store database.

Public Folder Hierarchies and Administrative Groups

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.

Top-Level Folder Creation

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


You can modify the default public folder store on all mailbox stores to point to only one common server. The disadvantage of this option is that it relies heavily on a single server, and users cannot browse the public folder hierarchy if the server is unavailable.

Figure 5.19 - Creating top-level folders on a dedicated public folder server

Top-Level Folder Permissions

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


Do not deny the Everyone account or the Domain Users group the right to create top-level folders. This would affect all users, including the administrators. Remember that denied permissions cannot be regranted through another account.

Content Indexing

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


Full-text indexes and catalogs consume approximately 20 percent of disk space of the corresponding store size. Keep this in mind when designing the hard disk subsystem of your servers.

Access to Public Folders

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 public folder referral process begins in the routing group that is local to the user’s default public store. This is not necessarily the local routing group where the mailbox store resides.

Public Folder Affinities

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


All connectors allow referrals by default and access to public folders is theoretically possible across the entire organization.

Public Folder Replication

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


Public folder replication works only between servers in the same organization. If you need to keep public folder instances between Exchange organizations synchronized, use the InterOrg Replication utility.

Controlling Public Store Sizes

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.

Developing a Public Folder Strategy

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


It is good practice to reassess your approach to public folder replication periodically. Exchange 2000 Server is flexible and allows you to create or eliminate public folder replicas at any time.

Table 5.2 Advantages and Disadvantages of Single-Instance and Replicated Public Folders

Single-Instance Public Folder Replicated Public Folder

Advantages

  • Public folder maintenance is centralized because only one public store is affected.
  • Additional disk space on other servers is not required.
  • There is no overhead or latency due to public folder replication.
  • A replica of a public folder can be kept available in all locations for local access.
  • Client access over WAN connections can be eliminated.
  • Fault tolerance between multiple servers is available.
  • Load balancing between multiple servers is possible.
  • Public folder replication can be scheduled.
  • Disadvantages

  • Bottlenecks in public folder access are possible if the public folder server is overtaxed.
  • Public folders are not available during server maintenance or unplanned downtime.
  • Underlying network topology determines quality of public folder access.
  • 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 to 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 messages traffic.
  • Developing a Public Folder Strategy for Adventure Works

    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."

    Activity: Developing Public Folder Strategies

    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


    You can use Figure B.16 in Appendix B as a guide to accomplish this activity.

    Scenario: Consolidated Messenger, Inc

    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.

    1. Which top-level folder strategy would you recommend for Consolidated Messenger?
    2. Where should you place the MAPI-based public folder hierarchy?
    3. Would you recommend creating an alternate public folder hierarchy for the Video department?

    Scenario: Litware, Inc.

    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.

    1. Which top-level folder strategy would you recommend for Litware, Inc.?
    2. How should you configure the public folder of the project documentation library to allow the users from Los Angeles and Washington, DC read access to the documents with optimal response times?

    Lesson Summary

    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.



    MCSE Microsoft Exchange 2000 Server Design and Deployment Training Kit(c) Exam 70-225
    MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)
    ISBN: 0735612579
    EAN: 2147483647
    Year: 2001
    Pages: 89

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net