Public Folders | Microsoft Exchange 2000 Server Adminstrator's Companion

[Previous] [Next]

Exchange 2000 Server makes several important changes to public folders. These changes include the following:

Administration of public folders is accomplished through the Exchange Folders Microsoft Management Console (MMC) snap-in.

Public folder trees are far more scalable and flexible. No longer are all of the public folders in your organization grouped into one large, monolithic hierarchy. You can now create public folder trees by geography, department, or function. The next section, "Multiple Public Folder Trees," discusses this feature in more detail.

Public folders are integrated with Active Directory, which means that mail entries enable you to send messages to a public folder instead of having to post directly to the public folder.

Public folders use the users and groups in the Active Directory directory service for security.

Accessing a public folder over the Web is more direct and much easier. With a standard URL, it's possible in Exchange 2000 to open up the contents of a public folder.

ExIFS, using SMB, makes public folder contents accessible from the file system for your LAN users.

Full-text indexing is built in with public folders. Outlook clients automatically use this new index when performing a Find or Advanced Find search. In Exchange 5.5, indexing of public folders is supported through Site Server, and that index is available only for Web clients to query.

Referrals are enabled by default. Public folder referrals enable clients to gain access to any folder in the organization because referrals between routing groups are now enabled by default.

Public folders can be created with the Exchange Folders snap-in. You are no longer required to use Outlook to create a public folder.

Multiple Public Folder Trees

In Exchange 2000 Server, you can create multiple public folder trees for a variety of purposes. For instance, suppose that you have a project team composed of three internal LAN clients, two users in your company at remote locations, and three consultants outside your organization. You can create a public folder tree for these users that is separate from the default public folder tree (Figure 2-11).

click to view at full size.

Figure 2-11. Multiple public folder trees.

Each public folder tree stores its data in a single public folder store on a per-server basis. You can replicate specific folders in the tree to every server in your company that has a public folder store associated with that public folder tree. The default public folder tree is available via MAPI, IMAP4, Network News Transfer Protocol (NNTP), and HTTP. Additional public folder trees are available only to HTTP and NNTP clients but not to internal LAN clients unless they use HTTP or NNTP to connect to the public folder tree.

Replication and Public Folders

By default, when a public folder is created, only one copy of it exists within the organization. If you like, you can replicate this public folder to other servers for redundancy, accessibility, and fault tolerance. Figure 2-12 shows how to use the Replication tab on the folder's property sheet to specify folders that will receive a replica of your public folder. You can also configure the replication schedule and the priority of the replication messages.

Figure 2-12. Specifying replication for a public folder.

Exchange 2000 clients really don't care which replica of a public folder they connect to. However, we administrators do care, for a variety of reasons. It is worth noting that when a client attempts to connect to a replica of a public folder, it looks for the replica in the following sequence of locations:

The client's default public store. This default is determined on the mailbox store's property sheet (Figure 2-13).

A server to which the client already has an existing connection.

Every other server that is in the same routing groups as the client's home public folder server.

Any other server in remote routing groups, based on the connector values between the home routing group and the remote routing group.

If two or more remote routing groups have the same connector costs, the servers containing the public folder replica are pooled together and selected at random as if they were in the same routing group. You should consider carefully before configuring a mailbox store to use a server in a remote routing group as its default public folder store. If you have slow or unreliable WAN links between your routing groups, your users may very well saturate your bandwidth if they heavily access public folders across the WAN link. It is best to choose a default public folder server that is in the same Windows 2000 site and Exchange 2000 routing group as the client's home mailbox store. In addition, consider pulling in replicas from remote public folder servers for clients who access these folders heavily.

Figure 2-13. The default public store for a client.

Security and Public Folders

Whereas previous version of Exchange used the security system embedded in the information store, Exchange 2000 Server uses the Windows 2000 Active Directory to enforce security. Hence, the new security model implements several important principles.

The first is that access control can be applied to any resource, not just the public folder. This capability enables you to apply security settings individually to items in the folder and to properties on the items. Second, Exchange 2000 Server no longer uses roles because the security system no longer emanates from the information store. Instead, permissions to administer Exchange 2000 Server are created in Active Directory. Third, as a further integration with Active Directory, the security identifiers (SIDs) for the user and group objects are used in the object's access control list (ACL). Anonymous access permissions are assigned to the special anonymous logon account, and default access permissions are assigned to the Everyone group. Finally, permissions can be denied on a per-user, per-object, or per-property basis. Deny permissions are processed first and take precedence over granted permissions.

NOTE
You can still use the Outlook client to assign permissions to a public folder. It will show the Exchange 5.5 style of roles and permissions, but Active Directory will not directly map these roles to Active Directory permissions.