A Public Folder Checklist

Public folders are a mixed blessing in an Exchange organization: They can be an effective way to add more functionality to the current installation, but their design and maintenance can bog you down. Decisions about design, content, permissions, and access can seem overwhelming at first, but with some foresight and planning, you can develop an easily managed deployment.

Before you put public folders into widespread use, you need to get organized, outline the folder hierarchy, and create folder policies. Opening folder permissions to anyone who asks, not securing folder permissions, or just winging the implementation is a guaranteed way to create unnecessary work down the line. A simple framework helps guide the design process and establish a solid foundation. Some elements to consider are the folder hierarchy, top-level permissions, client permissions, and sharing folder content.

Folder Hierarchy
The first step in creating the plan is organizing the folders. The root level of the public folder hierarchy is the initial view users see when they open public folders from their email client. In Outlook, the hierarchy appears in the folder list in the left pane. You need to arrange the root logically and set a clearly defined standard for the layout of these folders. You can display the folders by site name, business unit, folder function, department, or geographic location. Screen 1 shows a logically organized public folder hierarchy. A disorderly root littered with folders called Football Pool, Confidential Notices, and Fun Stuff can be confusing to users looking for specific information. A carefully planned hierarchy could have a Nonbusiness Items root folder (e.g., for Fun Stuff and Football Pool) and a restricted Confidential Notices folder. Preparation can shape the look and feel of the folders. When the root has little formal structure or no rules, you don't know what kinds of folders users will create or what they will put in them.

Top-Level Permissions
The next planning point to consider is who will have top-level administrative permissions. To assign this right, open the Microsoft Exchange Administrator program and go to the Top-Level Folder Creation tab on the Site, Configuration, Information Store Site Configuration page.

The top-level folder creation right lets the holder create folders on the root, so give this permission carefully. You don't want to give ordinary users permission to create folders at the root level because they might not conform to your folder hierarchy plan. Instead, give this permission to administrators who are responsible for maintaining the folder root hierarchy and public folder policies. These administrators can create new folders under the hierarchy at users' request and delegate administrative permissions to the folder owners without giving up complete control.

A handy way to assign this privilege is with Exchange distribution lists (DLs). You can create a DL and add it to the Allowed to create top level folders option on every site in the organization, as Screen 2 shows. By delegating folder administration permissions to users, you let them create items (including new folders) under their folder and modify permissions to those items; if problems develop, the administrator can still take control. This kind of structuring lets you regulate a corporate standard centrally but share the daily burden of subsequent folder creation, maintenance, and permission modification.

Client Permissions
After you plan the structure of your root folders and decide who will administer them, you need to decide how to assign permissions to users. I recommend using DLs to assign permissions to users, except the folder owner. Granting folder permissions to individual users weaves a tangled web of access that only the person who granted the permissions can understand. A better method is to create DLs with obvious names (e.g., Accounting Editors, St. Louis Reviewers, Production Contributors) and make users members of one of the lists. With this structure in place, you know what type of access users have because you know what their jobs are and therefore which lists they belong to. You might want to hide from the address book any DLs you create to keep users from accidentally mailing to them.

Using DLs to assign folder permissions also speeds up daily administrative tasks. Administrators creating new mailboxes can leverage the DLs by using another user in the same group or location as a template and referencing the DLs the original user has membership in. This technique eliminates searching through folder permissions to find what access the new user needs. Remember that you must select DLs within sites that you can connect to through Exchange Administrator and to which you have administrative access. You can't modify the membership or display names of DLs that are in sites to which you don't have access.

Permissions on folders apply to all the items contained within the folder; new folders created under a parent inherit the rights assigned to that parent. However, if you modify permissions on the parent folder, Exchange doesn't pass those changes down to existing folders by default. This behavior can be an obstacle if you want to add a new DL to every folder subnested in a deep tree. To overcome this problem, you can use Exchange Administrator to change the rights on all folders down a tree. Go to Folders, Public Folders, and select the folder you want to change. On the General tab of File, Properties, select the Propagate these properties to all subfolders check box, as Screen 3 shows. Choosing Client Permissions opens the same Client Permissions dialog box that you see when you right-click the folder in the Outlook folder hierarchy.

If you select the Propagate these properties to all subfolders check box and modify rights in the Client Permissions dialog box, the modifications will replace the current permissions of every folder from the selected one on down the hierarchy. This behavior is handy if you want to replace all existing permissions with a modified set, but replacing all permissions if you want to modify only one or two folders can cause trouble. Exchange gives you one last chance to choose precisely what to propagate after you complete the configuration. When you click OK or Apply, you see the Subfolder Properties dialog box that Screen 4 shows, which lets you select the specific properties you want to propagate down the tree. If you clear the Client permissions check box, the modifications will affect only the selected folder. Your goal is to understand which changes you want to make and where to make them.

The initial settings for all root folders are Author access for the Default account, None for the Anonymous account, and Owner for the folder's creator. All clients on all servers in the Exchange organization can see all the folders listed in the Public Folder hierarchy. The hierarchy is separate from the folder content; Exchange replicates the hierarchy to all servers in the Exchange organization by design. Users can see all the folders in the hierarchy, but they can't view the contents unless they have the correct client permissions.

One key variable for client access is the Folder Visible permission. You can use the Folder Visible permission to configure user access to folders, but you must use this permission carefully. Without this permission as a minimum, users can't see the folder in the hierarchy. If you look on the Client Permissions page of any folder that hasn't been modified, such as Screen 5, you can see that the Default user has the Folder Visible permission; that is, any user in the organization automatically receives the rights assigned to the Default user, including the ability to view all folders in the organization.

On the positive side, removing the Folder Visible attribute from the Default user prevents users from exploring potentially sensitive folders. This restriction might seem severe, but in a large installation with many folders, you might not want all users to see all the information that the folders contain. Even a folder's name can pique someone's interest and entice uninvited access. Making a folder invisible is better than letting users try to open it and learn they have no permissions.

Although hiding folders restricts users' mobility within public folders, this practice also helps users use the folders more efficiently. Eliminating folders that users can't access or don't need to view reduces the number of folders users see in the hierarchy. This limitation generates a personalized view of only folders in users' areas of interest or responsibility and thereby streamlines searches.

On the negative side, sometimes users might need access to a subnested folder, though they don't have Folder Visible permission to the folder's parent. Figure 1 illustrates this problem. In Figure 1, the Server Team folder is the root folder on the Exchange server; the Exchange Servers folder is subnested under the Server Team folder, and the Service Level folder is one level deeper. Joe is a member of a DL that has the Editor role on the Server Team folder. Joe maintains the service level agreements (SLAs) for the organization, so he also has the Owner role to the Service Level folder. However, some confidential folders are in the Exchange Servers folder, and Joe doesn't have permissions, including Folder Visible, at this level. The problems arise when Joe tries to work with documents in the Service Level folder. Even with Owner access to the folder, he can't get to this folder's contents because the parent folder doesn't have Folder Visible permission. To get around this obstacle, you can give Joe Folder Visible permission on the parent folder (Exchange Servers) temporarily, and he can add the Service Level folder to his Outlook Bar or his desktop as a shortcut. Then, you can remove the Folder Visible permission from the parent, and Joe will still be able to access the Service Level folder through the shortcut.

Not adding the Folder Visible property to the Anonymous role can also be problematic for sites planning to use Exchange with Microsoft IIS and Outlook Web Access (OWA). If Anonymous users want to access public folders from OWA, the folders' Anonymous role must have at least Folder Visible access. Although you could give the Anonymous role visible access to all the folders, a better plan is to have a specific root folder strictly for public folders that you want to share anonymously. You can then use Exchange Administrator to give Anonymous users access to the public folders. Under the Site, Configuration, Protocols object, double-click HTTP (Web) Site Settings. On the General tab, select the Anonymous access check box and create a shortcut for the set of folders you want to share.

Sharing Folder Content Between Sites
The basic function of public folders is to be a repository of information for users to share. Therefore, you need to distribute the folders' content between workgroups in different Exchange sites. This function can be the most involved part of your planning.

First, you need to examine the organization and decide how different sites need to access public folder content. The access strategies for sharing folder data differ in how they disseminate folder information to the various sites. Some approaches restrict access centrally, and others move the data around freely among the locations. Some folders contain data that users from multiple locations change constantly and that can't ever be out of sync. Other folders include information that changes infrequently and from only one site. You have several options for getting the folder data to users, including using single-instance folders, replicated instances, public folder affinity, or a combination of these methods.

Single-Instance Folder
The most straightforward way to share information is the single-instance folder. This technique creates one folder on one server in one location. The folder exists nowhere else in the organization, and no one outside the home site has access to it. The server on which you create the folder is the folder's home server; the site on which the server resides is the home site. You can use Exchange Administrator to find the Home Server and Home Site property of any folder. Select a folder, and open its Properties page. The Home Server property is at the bottom of the General tab. If you use only the single-instance folder method, access to the folder is limited to users who have a mailbox in the home site in which the folder exists. The folder appears in the hierarchy of all servers, but users in other sites can't view its contents.

The single-instance folder method is good for folders that contain site-specific information that people outside the site won't ever need. An internal discussion folder about facility-specific concerns, a regional entertainment folder, and other local information postings are good candidates for this type of storage.

Replicated Instance
In an environment with one site that contains multiple servers, all the servers in the site share access to one another's public folders by default. Users on server A in the site can access a folder on server B in the same site if they have permission to access the folder. However, heavy traffic to one folder will tax the resources of the server on which the folder resides. To alleviate this load, the administrator can replicate the folder to the servers in the site. Replication lets users read the folder's contents in their local Information Store (IS) rather than on another server in the site. Thus, replicating folders to other servers reduces network traffic and speeds up client connectivity.

Replication makes a physical copy of a folder and its contents from the public IS of one server to the public IS of another server. This method requires planning and consideration of bandwidth and resources. Replication speeds up client connectivity to the folders and minimizes the strain on WAN/LAN links by granting local rather than WAN access. Replication can, however, create additional WAN/LAN pressure because Exchange supports only document-level replication. If a user modifies a document in a folder, Exchange replicates the entire document, not just the change.

To determine the appropriate replication method, you must know how users will use replicated folder information. You might need to replicate some large folders that users modify every 12 hours only once or twice a day; other folders (e.g., folders that contain realtime sales data) might require more frequent replication intervals. You can create replication schedules globally on all folders or create schedules for individual folders that override the IS default.

Replication is an efficient strategy for organizations that have multiple user domains that haven't established trust relationships. Users on any domain can access a folder that has been replicated to their server if they have the correct client permissions.

If you decide to use replication, you must decide whether to pull or push folders around the organization. The push and pull methods accomplish the same results, but the interfaces and methodologies are different. Although you can use a combination of push and pull methodologies, using only one method can be simpler.

Push replication. The push strategy uses a folder-centric interface to replicate a folder from its home server to a remote server. To use the push replication method, connect to the folder's home site in Exchange Administrator. From Folders, Public Folders, select the folder you want to replicate. Click File, Properties, and on the Replicas tab, select the site and then the server in that site to which you want to replicate the folder. Screen 6 shows the settings for push replication.

The push method configuration is useful when you want to restrict control of the folder to one site. If you want to keep administrators in a remote site from pulling folder replicas from the local site, you must restrict administrative rights to the folder. On the home site, under Folders, Public Folders, select the folder you want to restrict. From Exchange Administrator, select File, Properties and on the General tab, select the Limit administrative access to the home site check box. This selection keeps anyone except local administrators in the site from replicating the folder to another site.

The push strategy offers tight control because the administrator can view which site and server any folder has been replicated to. However, this method requires administrative involvement because you must select each folder individually rather than selecting groups of folders. Exchange can replicate only one folder at a time.

Pull replication. The pull replication method uses a server-centric interface to replicate a folder from its home server to a remote server. To use the pull method, open Exchange Administrator, then go to Site, Configuration, Server, Public Information Store. Select File, Properties, and on the Instances tab, select the site and then the folder or folders you want to replicate to your public IS.

The pull method lets local administrators browse the public folders of a remote server and pick which folders they want to replicate to their local public IS. The decentralized nature of this technique cuts down on administration. You can add a folder from another server to your site without involving anyone else.

The pull method is appropriate for small organizations with few sites and a small administrative staff. The administrators in the remote sites can identify which folders their users need access to and pull a folder replica to their local IS without contacting the local administrator. If you want to prohibit remote sites from pulling a replica of a particular folder into their local IS, you can select the Limit administrative access to home site check box on that folder's Properties page.

Public Folder Affinity Affinity lets users in one site access a public folder on a remote site without having the folder information physically in the local server's public IS. Affinity gives open access to all the folders in a site as long as the user has the correct client permissions to the folder. However, affinity doesn't let you restrict access to only one folder.

To set up affinity, from Exchange Administrator choose Site, Configuration, Information Store Site Configuration. On the Public Folder Affinity tab, choose which sites you want to allow access to the folders in the local site. This page also offers a Connected site cost option that lets you assign higher cost to slower links and lower cost to faster links.

Affinity is a good option for small folders that change frequently and have time-sensitive data. Affinity creates one point of access; therefore, the data in the folder is always the most current. One point of access eliminates folder conflicts that can occur when several people access the same folder at the same time.

Affinity also facilitates easier folder administration and enhances security. All users who need to access a folder must come to one site. All users accessing the folder must have a Windows NT ID authenticated to access the domain with the Exchange server that contains the folder. If a user from domain X tries to view a public folder on a server in domain Y and the domains don't have a trust relationship, the user can't access the folder—even if the user has the correct client-level permissions on the folder.

Combination of Methods
In some cases, a combination of methods might be most appropriate. For example, suppose organization X initially has three production sites: A, B, and C. Each site is in a different geographic area, and a 128KB frame circuit connects the sites. Users in the sites share a series of folders that contain large production documents that users modify three times a day; 500 or more people in each site must access the folders many times during the day. In this situation, a good approach is to put the documents into a public folder and create a replicated instance of the folder on each of the three sites.

Now, suppose this organization adds a new site, D. The managers in site D need to read documents once or twice a week. Adding another replicated instance to site D wouldn't be a good strategy because of the bandwidth required for the few times the managers would access the folders. Affinity would be a more efficient way to meet the managers' needs. This mixing of techniques meets all the user requirements and still distributes the information in the most appropriate way. The folder is homed in one site, replicated to another, and made accessible by affinity to the third site.

Whichever method you select, you must carefully weigh the options and the consequences. Ultimately, the goal is to distribute the folder information in a way that maximizes user access while affecting the network infrastructure as little as possible. You can learn more about public folders by reading the articles in the "Related Articles" box.

A Systematic Approach
When you've made decisions about design, content, permissions, and access, you can begin deploying public folders. The plan gives you a clear definition of what the folders will look like, who will administer them, how you'll grant permissions, and how you'll distribute the information.