Recipe9.3.Getting and Setting Public Folder Permissions

Recipe 9.3. Getting and Setting Public Folder Permissions

Problem

You want to see, and possibly change, the permissions currently in effect on a public folder.

Solution

Using a graphical user interface

To view or change permissions, do the following:

Launch the Exchange System Manager (Exchange System Manager.msc).
In the left pane, expand the appropriate Administrative Groups container.
Expand the Folders and Public Folders nodes.
Right-click the folder you want and select Properties.
Switch to the Permissions tab and use one of the following three buttons:
- To control which users have permissions to create or modify items in the folder, and to assign roles to users, click the Client permissions button. You'll get the dialog box shown in Figure 9-1, from which you can assign granular user-specific permissions.
Figure 9-1. The Client Permissions dialog box lets you assign permissions for individual users on a public folder
- To control permissions on the public folder object in Active Directory (AD), click the Directory rights button; this displays the standard Windows ACL editor (see Figure 9-2). You will seldom need to do this; although, in some rare cases, it might be necessary to reset the permissions granted to the Exchange Domain Servers and Exchange Enterprise Servers groups.
Figure 9-2. Assign permissions on the public folder objects in AD if you prefer
- To control which users have administrative access to attributes of the public folder (like its ACL, replica list, and quota settings), click the Administrative Rights button. You'll see the same dialog box pictured in Figure 9-2, but with different permissions.
Set the permissions you want. As with any other permission-related operation, it's a really good idea to test the proposed permissions in a noncritical setting before making changes to your production network. When you're done, click OK.
Click OK to close the public folder properties dialog box.

To export existing permissions, do the following:

Open PFDAVAdmin.
From the menu, select File Connect; when the connection dialog appears, enter the name of the server whose replica list you want to export (and credentials if necessary).
Select Tools Options from the menu and make sure that the Enable logging to file checkbox is set. Specify a log file path if necessary and click OK.
Select Tools Export Permissions from the menu. The PFDAVAdmin Export Options dialog box will appear as shown in Figure 9-3.

Figure 9-3. Choosing export settings for public folder permissions
Select the scope of the export with the radio buttons in the Scope control group. The default is to export permissions for all public folders, but you can limit the export to a subscope if you prefer.
Choose a format for the exported permissions with the radio buttons in the Format group. You can export into three formats:
- The default format expresses permissions with the user's DN. This is the format that PFAdmin uses; when you export permissions using this setting, you can pipe the resulting output back to PFAdmin SETACL.
- The Account name (domain\user) radio button tells PFDAVAdmin to export the permissions using a more conventional (and readable!) format, with the domain and user name combined. PFAdmin can't read this directly, but it's still useful for maintaining records of permission changes.
- The XML radio button tells PFDAVAdmin to export the permissions using a custom XML format. You can reimport these permissions using PFDAVAdmin; it's also the best choice if you want to parse the permissions yourself, perhaps to generate reports or to analyze whether permissions meet your corporate standards. Note that PFDAVAdmin adds an informational header that may need to be removed before your tools will accept the file.
Click OK.
When the Save As dialog box appears, pick a name and location for your output file, and click OK.
Close the Export Permissions window.

Using a command-line interface

To dump public folder permissions, use PFAdmin with the LISTACL option, which also requires the name of the profile and the name of the folder (or ALL for all folders). You may optionally specify the name of a file to write the permission settings to if you want to replay them later with the O= option. Here's an example:

> pfadmin exAdmin LISTACL ALL O="c:\temp\pf-perms.txt"

To set public folder permissions, use PFAdmin with the SETACL option, which also requires the name of the profile and the name of the folder (or ALL for all folders), along with a list of rights. Normally, you'll use this command with a file generated by the LISTACL option; if you want to roll your own, you can run pfadmin ? SETACL to get a complete list of the syntax elements used to specify ACLs from the command line. The command:

> pfadmin exAdmin SETACL "Customer Complaints" johnp remove yes

will remove user johnp's access to the Customer Complaints folder and all subfolders contained therein.

Using VBScript

The process for doing this is too long and unwieldy to include here. However, Outlook MVP Eric Legault has a script that does the trick, and it's available from this book's companion web site (http://www.exchangecookbook.com).

Discussion

Public folders have a very flexible permissioning scheme compared to mailboxes. Table 9-1 shows the roles that you can assign to users; you can assign these roles with Outlook or with ESM, as described above. Each role is a composite of several individual permissions, which themselves are listed in Table 9-2. Although you can assign these permissions individually, in most cases you won't want to unless you need to assign unusually fine-grained permissions.

Table 9-1. Public folder roles
Role	Included permissions
Owner	Create items, Read items, Create subfolders, Edit All, Folder owner, Folder Visible, Delete All
Author	Create items, Read items, Edit Own, Delete Own, Folder Visible
Publishing Author	Author permissions, plus Create subfolders
Nonediting Author	Author permissions, minus Edit Own; this role can create new items, but not edit existing ones
Editor	Create items, Read items, Edit All, Folder Visible, Delete All
Publishing Editor	Editor permissions, plus Create subfolders
Reviewer	Read items, Edit None, Folder Visible, Delete None
Contributor	Create items, Folder Visible, Edit None, Delete None
None	Folder Visible, Edit None, Delete None

Table 9-2. Public folder permissions
Permission	What it allows
Create items	Holder may create messages in a folder, but not subfolders.
Create subfolders	Holder may create subfolders in this folder. Newly created subfolders inherit permissions from the parent folder, and the user who creates them gets Owner permission on them.
Delete items	Holder may remove items from the folder, according to the scope granted: None The holder can't delete anything. Own Allows the holder to delete items he created. All Allows the holder to whack any item in the folder.
Edit items	Holder may edit items in the folder, according to the scope granted: None The holder can't edit anything. Own Allows the holder to edit items she created. All Allows editing of any item.
Folder contact	Holder receives notification about things that happen to the folder, including when the folder goes over its permitted maximum size or when there's a replication or design conflict.
Folder owner	Holder owns this folder and has full control over it. The name of the last owner is never removed from the folder's ACL.
Read items	Holder may read any item in the folder. Without this permission, a user can't open the folder at all.
Folder visible	Holder can see that the folder exists.

When moving public folders from Exchange 5.5 to Exchange 2000 or 2003, the biggest issue you're likely to run into concerns permissions. The implementation of public folder permissions varies significantly between Exchange 5.5 and Exchange 2000/2003in fact, Microsoft has a very detailed white paper on the subject (see the "See Also" section of this recipe) that we won't attempt to duplicate here. Exchange 5.5 stores folder permissions in a table inside the IS, while Exchange 2000 and later store them as properties of the folder. There's a conversion process that maps the 5.5-style ACLs to the new format; that conversion may fail for a variety of reasons. If it does fail, permissions on the folder seem to disappear: Exchange 2000/2003 updates its copy of the ACL stored on the folder, and then replicates its changes back to Exchange 5.5! As a bonus, if the ACL contains an ACE listing an account that doesn't exist in Active Directory (as when a user account isn't replicated, or is deleted from Active Directory after replicating), the same problem will occur. To avoid this, Microsoft recommends using the DS/IS Consistency Adjuster (see MS KB 328287 and MS KB 836489) to groom your public folder ACLs before setting up any public folder connection agreements.