Using the Folder permissions option on the shortcut menu is approximately the same as modifying permissions using the Client Permissions button on a folder in ESM. The following figure shows the Permissions dialog box that is displayed when you right-click the shortcut menu, and then select Folder permissions. Explanations of the areas of the dialog box follow the screen shot.

Permissions dialog box

First, there is the name of the folder and the complete path that PFDAVAdmin is using to access the folder. The Add and Remove buttons let you modify the DACL by adding and removing entities. Underneath the Add and Remove buttons is the box that displays the current entities in the DACL and their roles.

Note:

The Everyone group is equivalent to Default in MAPI permissions, and ANONYMOUS LOGON is equivalent to Anonymous. Also, PFDAVAdmin adds an additional role to this interface, Folder Visible. In ESM, an entity that has no permissions and an entity that has only Folder Visible permissions will both appear with a role of None. PFDAVAdmin displays the former with a role of None, and the latter with a role of Folder Visible. Displaying this information makes it easy to see who has Folder Visible and who truly has None, instead of having to highlight each entity and examine the individual rights.

Response XML displays the raw XML DACL that was returned by the Exchange server. This representation does not include any modifications you made in the Permissions window. Instead, it displays how the DACL looked when you brought up the window without any interpretation by PFDAVAdmin. To see the XML that goes back to Exchange when you click Commit changes, use the Current XML button. Current XML shows you the XML as interpreted by PFDAVAdmin, including any changes that you made in the Permissions area up to this point.

The DACL state box is in the upper-right corner and indicates problems that PFDAVAdmin noticed when it interpreted the DACL. This box displays the following states:

• Good   The DACL has no noticeable problems.
  
• Contains unresolved SIDs   Some SIDs in the DACL could not be resolved. This makes it difficult to tell whether the DACL is truly canonical or not, because the ordering of ACEs in the DACL depends on the object type (such as a user versus a group), and the object type can only be determined if the SID can be resolved to an object in Active Directory.
  
• Missing Anonymous   When the ANONYMOUS LOGON entity is not present in the DACL, strange behavior can occur. The MAPI representation of the Client Permissions (such as that in ESM) will not reflect that Anonymous is missing. Anonymous will show up with a role of None even if it is not really there. Therefore, for example, users on the Internet can send e-mail messages to a public folder even when Anonymous permissions are apparently set to None. When you display Folder Permissions in PFDAVAdmin, Anonymous is automatically added to the in-memory representation of the DACL if it is missing, but PFDAVAdmin reports this situation in the DACL state box.
  

  Note:
  Missing Anonymous is typical and can be ignored for mailbox folders.

• Non-canonical order   The ordering of access control entries (ACEs) in an Exchange store DACL differs from the regular Windows access control entry (ACE) order. This difference is referred to as Exchange canonical order. Modifying folder permissions through Windows Explorer or other tools can put the DACL into a state in such a way that you can no longer modify Client Permissions through ESM or Outlook. PFDAVAdmin notices when a DACL is in a non-canonical format, and reports it in the DACL state box.
  
• Multiple allows/denies   In a typical Exchange DACL, each entity should have only one allow ACE and one deny ACE in each section of the DACL. If there are more allow or deny ACEs than that, the resulting permissions can be unpredictable.
  
• Allows without denies   Each allow ACE must be paired with a deny ACE, unless the mask for the deny ACE would be 0. This status indicates that a nonzero deny mask is missing.
  
• Invalid Masks   After interpreting the rights for an entity based on the access masks, PFDAVAdmin generates new access masks based on those rights. If the masks generated do not match existing masks, the Invalid Masks status is shown. This status means that an additional flag has been set or cleared that does not correspond to a valid right.
  

The Options area contains two check boxes that modify the behavior that occurs when you click Commit changes. When these two boxes are not selected, the XML you see in Current XML is written to the folder and replaces the previous permissions.

• Wipe existing DACL before committing   Selecting this check box causes an empty DACL to be written to the folder first, before the new permissions are written. Having an empty DACL written before new permissions are written can be helpful in resolving certain permissions issues.
  
• Force canonical order and valid masks   Selecting this check box causes PFDAVAdmin to iterate through each entity in the DACL when you click Commit changes. It arranges the ACEs for that entity according to Exchange canonical ordering. Any unresolved SIDs are removed because PFDAVAdmin cannot determine the ordering for those entities. Then, it interprets the access mask and clears any bits that do not correspond to a valid Exchange right.
  

When you select these two check boxes and then click Commit changes, all DACL problems on the folder should be corrected.

Repair Roles is for use when the DACL has been changed through, for example, Windows Explorer, which may have put it in non-canonical order and given the ACEs invalid access masks. After the DACL has been changed using Windows Explorer, and you view the DACL through PFDAVAdmin, you will frequently see that the entities mostly have roles of Custom. Clicking Repair Roles will sometimes be able to change these damaged roles back to what they were before. However, this usually does not work for the Everyone group.

After you select the Propagate folder ACEs option, you can use the Propagate ACEs option to propagate individual changes to the DACL without overwriting all permissions.

1. In the context menu, right-click Propagate folder ACEs to display the Propagate dialog box.

2. In the Propagate ACEs dialog box, select the names that you want to add, replace, or remove.

3. Click Add/replace to add or replace the selected entities to all subfolders with the role. If the entries are already in the DACL on that folder, the permissions for those entities are changed to the propagated permissions.

4. Click Remove to remove the selected entities from the DACL regardless of the role. The role has no effect in this case; the selected entities are removed from the DACL regardless of the role.

5. Click OK.

Use the Fix Folder DACLs option to correct DACL problems on many folders at the same time. Fix Folder DACLs is equivalent to displaying the Permissions dialog box, selecting the Force canonical order and valid masks check box, and then clicking Commit changes. The following figure shows the Fix Folder DACLs dialog box.

Fix Folder DACLs dialog box

Select the following options, based on your requirements. When you finish making your selections, click Execute.

• In the Folder selection, select either Only the selected folder or The selected folder and all subfolders.
  
• In the Mode section:
  
  • Read-Clear-Write is equivalent to selecting the Wipe Existing DACL check box in Folder Permissions.
    
  • In the current version of PFDAVAdmin, the default mode is Read-Write. This mode is equivalent to clicking Commit changes in Folder Permissions without selecting Wipe existing DACL before committing.
    
  • Write mode replaces the DACL on all the folders that have the same permissions that you specify. This is the fastest mode, but all previous permissions on the folders are lost.
    
• The Attempt to upgrade damaged roles check box is the equivalent of the Repair roles button in Folder Permissions. Before you run Fix Folder DACLs, you should use Folder Permissions to check your permissions. Then you can configure the Fix Folder DACLs settings based on what worked best for you in Folder Permissions.
  
• The Remove mail-disabled entities check box causes PFDAVAdmin to examine each SID in the DACL to determine whether the Active Directory object has the mailnickname attribute populated. PFDAVAdmin does this by querying Active Directory for a match on objectSID, sidHistory, or msExchMasterAccountSid. If an Active Directory object is not found, or one is found but mailnickname is not populated, that SID is removed.
  

Use the Check DACL State option to select the DACL state on several folders at one time. This option reports the same information that you would see in the DACL State check box on the Folder Permissions page for a specific folder. With regular logging, the name of each folder is listed as it is processes, and only problems are reports. At the end, a summary is provided that lists every folder that had a DACL problem.

With extended logging turned on, the message "DACL is good" is reported on every folder, even those that do not have a problem. This additional content could lead to a very congested log.

Use the Check for item-level permissions option to read the security descriptors on all items in one or more folders, and report the number of items if any item-level permissions are found. The security features are read on all items at the same time, instead of requesting them individually. If extended logging is turned on, the name of each item is reported.

Use the Remove item-level permissions option to delete permissions from all items in a single request.

Note:
You can remove item-level permissions only from items that have such permissions, or you can clear the security descriptor on all items.

You may want to run this operation against items that do not have item-level permissions because this is an easy way to update all items in a folder. This action forces all the items to replicate. The public store tries to replicate the updated items, even though clearing the security descriptor on an item that has no item-level permissions has no functional effect on the item.

1. Connect to the public folders.

2. Right-click Public Folders, and then select Remove item-level permissions.

3. Select The selected folder and all subfolders.

4. Click Execute.

When this operation is completed, all item-level permissions should be removed from all items in all public folders. Repeat this process for mailboxes, if it is required.

Use the Propagate replica list option to add or remove replicas from several folders at the same time, for selected servers.

1. Select the appropriate server.

2. Click Add or Remove.

3. Click OK.

Use the Check for event registrations option to scan a tree of folders for event registration items. This option provides an easy way to locate all event registrations throughout the public folder tree.

Use the Property Editor option to display and modify MAPI properties on the selected folder. You can also perform the same action on all subfolders if you want. The following figure shows the Property Editor dialog box.

Property Editor dialog box

If you select Perform this action on all subfolders of the selected folder, the results are logged to the output pane at the bottom of the window. If you choose to perform a bulk operation, a separate window will open and the logging options from the Options window will be used. If the selected folder is the root Public Folders object, the bulk operation applies only to subfolders.

The Property list provides a list of common properties. You can use this list or you can manually enter a property tag for any properties that are not in the list. Currently, PFDAVAdmin supports only the Set action on properties of type PT_BOOLEAN, PT_LONG, PT_STRING8, and PT_BINARY.

Bulk property operations are useful in several situations. For example, there are situations when you want to clear the PR_PF_PROXY attribute on all public folders. Also, when you troubleshoot problems where an event is identifying a problem folder by folder ID (FID), it can be helpful to display the ptagFID property for all folders. These types of operations are what the Property Editor is intended for.

Caution:
Be careful when you use the Property Editor. Modifying certain properties may have unintended or unwanted results, and performing such modifications on a whole tree of folders may be difficult or impossible to reverse.

The Show deleted subfolders option causes PFDAVAdmin to enumerate any deleted subfolders of the currently selected folder. Note that deleted folders are preserved only if Deleted Item Retention has been configured on the public store. Any such folders appear in red. If you right-click a deleted folder, you have the option to recover it. Using Recover Folder can be useful when the recover option in Outlook or Outlook Web Access is failing.

The right pane of PFDAVAdmin contains a set of tabs for interacting with the folder selected in the left pane. The tabs do the following functions.

Tab name	Function
Subfolders	Displays the subfolders of the selected folder. This tab contains the same context menu as the left pane.
Items	Displays all the items in the folder. Right-click to display a context menu that lets you clear item-level permissions on individual items, or display the XML representation of the permissions on items. At the bottom of this tab, you also have the option to view any deleted items that are still present because of deleted item retention. When you right-click deleted items, a menu option is provided to recover them. The Items tab will display nothing if PFDAVAdmin is connected to an Exchange server without replica. Note:
Replicas	Lets you add or remove replicas for the selected folder. The same functionality is available in ESM.
Limits	Lets you modify limits on the public folder, using values up to 2,147,483,647. This option overcomes a limitation imposed by the ESM user interface. In ESM, the maximum value that can be used on the Limits tab is 2,097,151. However, you can use larger limits. On a mailbox, you can change mDBOverHardQuotaLimit, mDBOverQuotaLimit, and mDBStorageQuota on the Active Directory object. However, limits on public folders are stored in the Exchange store instead of on the directory object for the public folder.
Events	Displays event registration items in the folder. For viewing only. You cannot modify event registrations through PFDAVAdmin.

The Tools menu presents the following options.

• Import
  
• Export Permissions
  
• Export Replica Lists
  
• Export Properties
  
• Content Report
  
• Set Calendar Permissions
  
• Custom Bulk Operation
  
• Options
  

Import

Input file format:
    SETACL <tab> Folder <tab> User <tab> Rights[ <tab> User <tab> Rights]...
                                                          [ <tab> YES|NO]

    Folder  = public folder name
    User    = user account to set rights for
    Rights  = rights to set for the user
              Rights by Role:
                 Owner (O), PublishingEditor (PE), Editor (E),
                 PublishingAuthor (PA), NoneditingAuthor (NA),
                 Author (A), Reviewer (R), Contributor (C), None (0)
              Specific Rights:
                 Read (r), Write (w), WriteOwn (wo), Create (c),
                 CreateSubfolder (cs), Delete (d), DeleteOwn (do),
                 _Owner (o), Contact (t), Visible (v)
              Other Rights Specifications:
                 All (L) - same as Owner|Contact
                 Remove (X) - deletes existing entry for the user
    YES|NO  = apply changes to subfolders?

Input file format:
    SETREPLICAS <tab> Folder <tab> Option <tab> Server(s)
        [ <tab> Option <tab> Server(s)]...[ <tab> YES|NO]

    Folder    = public folder name
    Option    = ADD server(s) to replica list
                DELETE server(s) from replica list
                REPLACE replica list with server(s)
    Server(s) = [Site\]Server[,[Site\]Server]...
    Site      = replica site  (default = same site)
    Server    = replica server
    YES|NO    = apply changes to subfolders?  (default = YES)

Export Permissions

Export Replica Lists

Export Properties

The Export Properties option lets you export both store properties and directory properties for a folder to a tab-delimited file. These exports are for reporting purposes only — they cannot be imported with any tool. When you select Export Properties, the PropertyExportForm dialog box is displayed as shown in the following figure.

PropertyExportForm dialog box

This list contains the same store properties as Property Editor, but there are some properties at the top that are prefixed by DS:. These properties are retrieved from the Active Directory object that corresponds to the public folder. You can add any properties that you want to the list by typing them in the space provided at the bottom and clicking Add property to list. Store properties must be specified by a property tag, such as 0x671D0102. DS properties must be entered as DS:propertyName.

To generate the export, specify an output file at the top, select any properties that you want, and then click OK. You can open the resulting tab-delimited file in Microsoft Office Excel®.

Note:

Selecting the DS:ntSecurityDescriptor attribute does not export the entire ntSecurityDescriptor from the directory object. The purpose is to identify anyone who has been granted Send As rights on the folder. Therefore, when this attribute is selected, PFDAVAdmin only exports explicit permissions on the object that grants Send As rights. This includes either an explicit Send As or All Extended Rights. Any inherited permissions and any explicit permissions that do not relate to Send As are not exported.

Content Report

Set Calendar Permissions

Custom Bulk Operation

Options