共用方式為

  • 發行項

Microsoft Exchange Server Public Folder DAV-based Administration Tool

 

Topic Last Modified: 2007-06-19

The Microsoft® Exchange Server Public Folder Distributed Authoring and Versioning (DAV)-based Administration tool, version 2.8 (PFDAVAdmin 2.8) is an Exchange Server tool that you can use to perform several tasks related to public folder management. Tasks include the following:

  • Modify folder permissions on folders in the MAPI tree by using an interface similar to Exchange System Manager (ESM).

  • Propagate the addition, replacement, or removal of one or more access control entries (ACEs) in the public folder tree without overwriting the entire access control list (ACL).

  • Fix non-canonical (does not follow standards) and otherwise damaged discretionary access control lists (DACLs) on folders in bulk.

  • Export and import folder permissions on public folders and mailboxes.

  • Export and import replica lists.

  • Propagate changes to the replica list in the tree without overwriting.

  • Look for and remove item-level permissions in bulk.

  • Look for event registrations.

  • Exceed the limits imposed by the ESM user interface for values on the Limits tab.

  • Display and modify folder properties in bulk.

  • Modify folder permissions in bulk selectively on folders by creating filters.

  • Modify the permissions of the Calendar folder in bulk.

Note

This tool accesses the Exchange store using WebDAV. Therefore, bulk operations can be slow and can take a long time to complete when you run it against thousands of folders on Exchange 2000 Server. When you run the tool against Exchange Server 2003, the operation takes less time, and is faster.

Warning   Users are cautioned to store the export and log files in a secure location, where they are not available for access by everyone. Folders should be created and have the appropriate permissions set so that only users who have the restricted permissions can access and save the PFDAVAdmin export and log files in that location.

System Requirements

PFDAVAdmin 2.8 must be run on a computer that has the following:

  • .NET Framework 1.1

    Note

    You can run PFDAVAdmin if you also have .NET Framework 2.0 on your computer. However, you do not have to have version 2.0 on the computer, but you must have .NET Framework 1.1 installed.

  • Microsoft Windows® 2000 Server, Windows XP, or Windows Server™ 2003, Windows™ Vista

  • Exchange 2000 Server, Exchange Server 2003, or Exchange Server 2007

Working with Event 9551

Read this section carefully to obtain a full understanding of why you should avoid changing permissions through PFDAVAdmin when you are seeing event 9551 in your environment.

When a public folder replicates over to Exchange 2000 Server or Exchange Server 2003 from Exchange Server version 5.5, the permissions from Exchange Server 5.5 are stored in ptagACLData, which is the legacy ACL that has permissions based on legacyExchangeDN. When a client on Exchange 2000 Server tries to access a public folder, a new SID-based ACL is used - ptagNTSD. When ptagACLData contains permissions, Exchange 2000 Server must query Active Directory for each legacyExchangeDN listed in ptagACLData, and get the SIDs for those users so it can move the permissions into ptagNTSD. When it cannot find a legacyExchangeDN, an event 9551 is generated and the permissions from ptagACLData cannot be upgraded.

This situation results in ptagACLData containing permissions that are not visible in ptagNTSD. By default, when a single legacyExchangeDN from ptagACLData cannot be found, the store does not promote any of the permissions to ptagNTSD except entries with Owner permissions (if their domain names can be resolved).

PFDAVAdmin views and directly modifies ptagNTSD. When you use a tool such as Exchange System Manager (ESM) or Microsoft Office Outlook®, both of which change the permissions through MAPI, you will see the legacy ptagACLData information. In PFDAVAdmin, you see only what ptagNTSD actually contains. If a user cannot access a folder, and you suspect that the ACL upgrade has failed, using PFDAVAdmin is an easy way to see what ptagNTSD contains, which is who actually has permissions to access the public folder that is stored on Exchange 2000 Server or Exchange Server 2003. If you can see their permissions on the folder in ESM, but not in PFDAVAdmin, and in PFDAVAdmin you can only see Owners on the folder, the ACL upgrade has failed.

You cannot completely correct a failed ACL upgrade through PFDAVAdmin. For the ACL to upgrade, the store must be either able to find legacyExchangeDN in Active Directory or must be told to ignore domain names that it cannot find (for example, by using the Ignore Zombie Users registry value).

If you edit an ACL in this state in PFDAVAdmin, the legacy ACL information will be lost. If you are not concerned with the old permissions, you should still be cautious making any ACL changes in PFDAVAdmin when you see event 9551 in your environment. This caution includes using Fix Folder DACLs and Propagate Folder ACEs. Running either of these options will definitely “correct” any event 9551 messages. However, it will do so by eliminating the legacy ACL information that did not upgrade.

Conversely, any operation that causes ptagNTSD to be evaluated triggers an attempt to upgrade ptagACLData. Running Export Permissions from PFDAVAdmin is a good way to “touch” all the public folders and cause the store to immediately attempt an ACL upgrade, which will reveal any event 9551 problems. Because running an export only reads the permissions and does not modify them, any permissions that fail to upgrade remain in ptagACLData.

For more information about how to work with event 9551, search the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?linkid=31845) and use 9551 as your search query. An example of one of the many Knowledge Base articles is 328880, "How to troubleshoot public folder performance issues that are related to ACL conversions in Exchange 2000 and in Exchange 2003" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=328880).

Installing PFDAVAdmin

Download the tool (PFDAVAdmin) from the Tools for Exchange Server 2003 Web site at https://go.microsoft.com/fwlink/?linkid=55032 and save it to a directory of your choice. You can also download the tool from the Tools for Exchange Server 2007 Web site at https://go.microsoft.com/fwlink/?linkid=81741.

Connecting to an Exchange Server

After you start PFDAVAdmin, you must connect to an Exchange server before you can do any tasks. When you click File from the PFDAVAdmin main menu and then click Connect, the following dialog box appears.

Connect dialog box

2a659fa5-c62d-453a-b322-abde8a6e2531

Enter the appropriate information, and then click OK. PFDAVAdmin connects to a domain controller (global catalog server) that you specified to read the primary Simple Mail Transfer Protocol (SMTP) address on the default recipient policy. PFDAVAdmin uses this information to know what domain name is used in the Installable File System (IFS).

Note

In the earlier version of PFDAVAdmin, the computer from where you ran PFDAVAdmin had to be a member of the same forest in which the target Exchange server resided. This requirement is no longer valid. You can now run it from a computer that is not a member of the same forest as the target Exchange server.

  • If you select Public Folders, PFDAVAdmin tries to connect to the public store on the target Exchange server over Secure Sockets Lauer (SSL) port 443 port and to populate the navigation pane with the top-level folders. If this connection fails, PFDAVAdmin retries the connection using port 80 (non-SSL).

Important

Be aware that there is a security risk if SSL is not enabled. For information about how to enable SSL, see "Configuring Exchange 2003 for Client Access" at https://go.microsoft.com/fwlink/?linkid=91843.

  • If you select All Mailboxes, the process is more complex. First, PFDAVAdmin obtains the properties of all HTTP virtual servers on that server. Next, it queries a global catalog for all the mailboxes that are homed on that server, based on msExchHomeServerName. When it has the list of mailboxes, it reads each proxy address on each mailbox and tries to match it with the domain name on one of the HTTP virtual servers. Based on that information, an HTTP path is built to that mailbox. For Exchange Server 2003 Service Pack 1 (SP1) and later versions, PFDAVAdmin tries to connect to the mailboxes over Secure Sockets Layer (SSL) port 443 first. If this connection fails, PFDAVAdmin retries the connection using port 80 (non-SSL). For Exchange Server 2003 without a service pack, and for Exchange 2000 Server, PFDAVAdmin uses only port 80 (non-SSL).

  • If you select Specified mailbox, PFDAVAdmin tries to connect to the mailbox directly over Secure Sockets Layer (SSL) port 443, just like it does to the public store. Again, if this connection fails, PFDAVAdmin retries the connection using port 80 (non-SSL).

  • If the user has an e-mail address that matches one of the addresses on the default recipient policy, the HTTP path uses the Exadmin virtual directory through the default HTTP virtual server, which enables the root folders in the mailbox to be displayed. Otherwise, the HTTP path uses one of the other virtual servers, and the root folders are not displayed. PFDAVAdmin does not try to connect to the store until you expand one of the mailboxes.

    Note

    You must be authenticated as a user who has permissions to access that mailbox. By default, a user who has Exchange Full Administrator rights does not have these permissions.

After you successfully connect and the left pane of PFDAVAdmin is populated with folders, you can continue with PFDAVAdmin tasks. For operations, there are pull-down menus along the top of the screen, and you can also right-click a folder in the left pane, or on the Subfolders tab, to display a shortcut menu.

Using PFDAVAdmin

This section explains how to perform tasks with PFDAVAdmin.

Correcting Permissions Problems

Although PFDAVAdmin can be used for several tasks, the most common usage is to correct permissions problems after drive M has been scanned, or permissions have been modified through some other non-MAPI interface.

How to correct permissions

  1. Connect to the public folders.

    Note

    Before you try to fix your public folder permissions, it is recommended that you take a snapshot of your current public folder permissions. To take a snapshot, locate Tools\Export Permissions, and use the XML format. XML is the best format to use for a quick snapshot of the exact permissions on each folder.

  2. After you export the existing permissions, right-click Public Folders, and then select Fix Folder DACLs.

    Note

    Fix Folder DACLs removes permissions for any unresolved security identifiers (SIDs). It is recommended that you run Check DACL State and look for any folders that contain unresolved SIDs before you run Fix Folder DACLs. If these unresolved SIDs are the result of a broken trust or other Microsoft Active Directory® directory service problems, correct these problems before using Fix Folder DACLs. Also, consider how this can affect folders that are generating 9551 event messages.

  3. Select The selected folder and all subfolders.

  4. Select Read-Clear-Write or Read-Write. Typically, Read-Write is sufficient and slightly faster than Read-Clear-Write.

  5. Select Attempt to upgrade damaged roles.

    Note

    Although this option is not required to fix the permissions, in most cases it is desirable. If you do not select this check box, many of the permissions could end up with a role of Custom. Also, this option usually does not work for the Everyone group, and it will end up with a role of Custom anyway.

  6. Click Execute.

After this process finishes running, you should again be able to change the permissions on all public folders through ESM and Outlook. If it is required, repeat this process for mailboxes.

Using the Shortcut Menus

Much of the functionality of PFDAVAdmin is accessed by using the shortcut menu. Right-click a folder in the left pane or on the Subfolders tab, and the shortcut menu displays the following options.

  • Folder permissions

  • Propagate folder ACEs

  • Fix folder DACLS

  • Check DACL state

  • Check for item-level permissions

  • Remove item-level permissions

  • Propagate replica list

  • Check for event registrations

  • Property Editor

  • Show deleted subfolders

Folder Permissions

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

9dbd84c0-d440-4e06-adcb-328e94e2293f

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.

Propagate Folder ACEs

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.

How to propagate the ACEs to all subfolders

  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.

Fix Folder DACLs

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

3778377a-cd8c-4130-8186-44dd3cebdffd

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.

Check DACL State

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.

Check for Item-Level Permissions

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.

Remove Item-Level Permissions

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.

How to remove item-level permissions on the selected folder and all subfolders

  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.

Propagate Replica List

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

How to select the replica list entries to propagate

  1. Select the appropriate server.

  2. Click Add or Remove.

  3. Click OK.

Check for Event Registrations

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.

Property Editor

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

1befcf5d-5b29-4d4c-8787-e032f66ae658

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.

Warning

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.

Show Deleted Subfolders

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.

Tabs

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.

Note

The Items tab will display nothing if PFDAVAdmin is connected to an Exchange server without replica.

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.

Tools Menu

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

The Import option lets you import several types of files.

  • PFAdmin-style imports using theSETACLcommand, such as that generated by OutlookFolders or PFInfo (or PFDAVAdmin). Users can be specified by display name or by legacyExchangeDN. These files can also be imported by using PFAdmin 1.3.

    Note

    When you import SETACL commands, remember that the PFAdmin format uses either the display name or legacyExchangeDN to specify the user. During the import, PFDAVAdmin must resolve the name or domain name to an SID. If you have more than one mail-enabled object that has the same display name, PFDAVAdmin cannot apply permissions for that user. This situation will be reported as an ambiguous name in the import log.

  • PFAdmin-style imports using the SETREPLICA command, such as replica exports generated by PFDAVAdmin. These files can also be imported by using PFAdmin 1.3.

  • PFDAVAdmin permissions exports in NT Account name (Domain\User) format

  • PFDAVAdmin permissions exports in XML format

The following excerpt from the PFAdmin syntax help explains the SETACL command format. Note that PFDAVAdmin ignores the trailing YES or NO. In exports, PFDAVAdmin adds the trailing NO for compatibility with PFAdmin.

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?

When you import SETREPLICA commands, PFDAVAdmin must resolve the server name to the legacyExchangeDN of the public store for that server object in Active Directory. The PFAdmin format lets you specify SITE\SERVER or just SERVER in the import. PFDAVAdmin ignores the SITE if specified in the import. It matches the server name with an Exchange server in any administration group regardless of what is specified for SITE.

The following excerpt from the PFAdmin syntax help explains the SETREPLICAS command format. Again, PFDAVAdmin ignores the trailing YES or NO.

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

The Export Permissions option displays the PFDAVAdmin Export Options check box that enables you to select scope and format.

How to select the scope and format when exporting permissions

  1. In the Scope area, select either All public folders or Selected folder and subfolders.

  2. In the Format area, select one of the following:

    • legacyExchangeDN format is the only type of export that can be imported with a tool other than PFDAVAdmin. Use this format to generate exports that match the format of OutlookFolders or PFInfo. This format lets you import the file with PFAdmin 1.3 from the Microsoft BackOffice® Resource Kit. There is one difference from OutlookFolders or PFInfo: PFDAVAdmin specifies users by legacyExchangeDN in the export instead of by display name. This difference avoids issues with ambiguous display names when importing.

      Note

      Only public folder permissions exports can be imported with PfAdmin 1.3. You can export mailbox permissions in legacyExchangeDN format, but mailbox permissions can be imported only with PFDAVAdmin.

    • Account name format is the same as was mentioned earlier, except that users are specified as Domain\User instead of by legacyExchangeDN. Depending on what you want to do, account name format may be more useful. However, these exports can be imported only with PFDAVAdmin.

    • XML format is a file dump of the XML representation of the DACL from each folder exactly as returned by the Exchange store. Exports and imports in this format are very fast because no translation or resolution of names is required. However, imports in this format set the DACL exactly as shown in the export; all existing permissions are replaced by the snapshot of the XML in the export. The other formats append to the existing permissions instead of overwriting the entire DACL.

      Note

      The XML format is ideal for taking a snapshot of folder permissions in a particular state and being able to quickly put them back into that state. If you intend to generate an export, modify it, and then import it, XML is not a good choice. The XML is difficult to read and modify for those not familiar with it.

  3. Click OK.

Export Replica Lists

The Export Replica Lists option exports the replica lists for the selected folders to a file that uses the PFAdmin SETREPLICA command format. This export always uses the REPLACE command, so that importing the file resets the replicas on the public folders to the state they were in at the time of export. You can manually modify the file (or create your own file) and use the ADD or DELETE commands, which PFDAVAdmin recognizes.

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

cc47c04a-3dbd-4fbd-a9fb-bbd693a0be24

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

The Content Report option is similar to Export Properties because it writes information to a tab-delimited file. However, a Content Report iterates through all the items in each folder to gather information that cannot be read from the properties of the folder itself. You can create a report for all the public folders or any single public folder and its subfolders with information such as the following:

  • Folder Path   The path of the folder.

  • PR_DISPLAY_NAME   The display name of the folder.

  • PR_CONTENT_COUNT   The item count as shown on the folder properties.

  • PR_MESSAGE_SIZE_EXTENDED   The size of the folder as shown on folder properties. Works for values both under and above 5 GBs.

  • Total Number Of Items   The number of objects that PFDAVAdmin found in the folder.

  • Oldest Creation Date   The oldest creation date of any item in the folder.

  • Oldest Modification Date   The oldest modification date of any item in the folder.

  • Newest Creation Date   The most recent creation date of any item in the folder.

  • Newest Modification Date   The most recent modification date of any item in the folder.

  • Largest Item Size   The largest item size in the folder.

  • Total Calculated Size Of Items   The total of all individual item sizes added together.

For example, by looking at the Newest Creation Date and Newest Modification Date, you can probably determine how frequently the folder is used. If the report shows dates of many years ago, the folder may not actually be being used any longer. You may want to consider adding age limits to folders to delete contents that have not been used for years, being sure to give users a deadline to deal with the contents. Or, you may want to delete the contents or archive them to different storage if you are confident that they are no longer required.

You may also want to examine the PR_MESSAGE_SIZE and Total Calculated Size Of Items to see which folders are taking up space on your hard disks. By using Export Permissions (on the Tools menu, click Export Permissions), you can see who has the owner permissions for those folders. Then, you can contact the owner to confirm that it is OK to delete those folders.

Remember that, like every other function in PFDAVAdmin, Content Report runs only against the server that you are pointing it to. That is, folders that do not have replicas on the target server will have a blank line in the report. If you have multiple replicas of a folder that are out of sync with each other, you may see different information for a folder depending on which server you point it at. Therefore, if you suspect that your replicas are out of sync, check this by running Content Report against those servers and comparing the results. To synchronize your replicas, consider using Synchronize Hierarchy in ESM available with Exchange Server 2003 Service Pack 2 (SP2). Or, add a replica using PFDAVAdmin.

Also note that PFDAVAdmin does not report Last Access Time, because that data is unavailable through DAV. In fact, the act of using PFDAVAdmin to analyze the folder content will cause the Last Access Time (visible in ESM under the public store for each server) on that folder to update on that target store. If you plan to correlate the Last Access Time with the data from the Content Report, you must gather the Last Access Time first. Also, remember that Last Access Time is specific to each store. If you plan to use that data, you need to get it from each public store. Another possibility that the Last Access Time can be updated “unintentionally” is file level virus scanning (which was a bigger problem on Exchange 2000 servers that have the exposed drive M). When folders are scanned in that way, the Last Access time is updated at every virus scan so the Last Access Time is probably not a good indication of whether real users accessed the contents at that time.

Set Calendar Permissions

The Set Calendar Permissions option enables you to perform a bulk edit specifically to change permissions of the Calendar folder so that a single operation can modify the settings of thousands of users on a server. This is useful for changing the default permissions setting of the Calendar folder of all or many users, so that team members can view other member's calendars. Using Microsoft Office Outlook® enables changing only one user at a time, so the Set Calendar Permissions option is a good solution for this kind of task.

In addition to changing the permissions of the Calendar folder, by using this option, a bulk-change also occurs on the permissions of the FreeBusy Data folder (hidden folder) of all the users on a server. If the FreeBusy Data folder permissions were not changed, the users will not be able to access another user's calendar.

For more information about how to access another user's calendar, see Microsoft Knowledge Base article 237924, "PRB: AC: Outlook 2000 Doesn't Properly Read ACL Settings" at https://go.microsoft.com/fwlink/?linkid=3052&kbid=237924.

Custom Bulk Operation

The Custom Bulk Operation option enables you to perform a bulk edit based on user-defined filters and conditions. Although PFDAVAdmin has several bulk edit functions, this option allows for selectively performing an option on folders that match certain conditions. For example, apply foo/administrator as Owner only on the public folders created after 5/5/2006.

The user can create an LDAP-like filter so that an operation is performed on the folders that match the defined filter. Users can also create subfilters on the operation level to specify which operation will be applied to folders that match the subfilters. An example of the filter and its results is as follows:

Overall Filter

(|(0x3001001E=FOO1)(0x3001001E=FOO2))

Operation Filters

  1. Folder Permissions Merge DomainFoo\Administrator;Editor(0x3001001E=FOO1)

  2. Folder Permissions Merge DomainFoo\Administrator;All (0x3001001E=FOO2)

Results

  • For the public folders where the DisplayName is ‘FOO1’, user ‘DomainFoo\Administrator’ will be granted an Editor right

  • For the public folders where the DisplayName is ‘FOO2’, user ‘DomainFoo\Administrator’ will be granted an Owner right

The Set Calendar Permissions option uses the Custom Bulk Operation option by creating a set of specific filters.

Options

The Options option displays the logging options. These settings are saved to the registry at HKEY_LOCAL_MACHINE\Software\Microsoft\pfDavAdmin. It also saves the name of the Exchange server and global catalog server that you last connected to.

Currently Required DAV Verbs

The following table defines the verbs that are currently required for the PFDAVAdmin tool for full functionality and for the tool to work correctly. If you are running applications (for example, UrlScan Security Tool) that can restrict certain DAV verbs, make sure that the following verbs are allowed.

SEARCH

Move down the hierarchy in both the user interface and all the worker classes.

PROPIND

Read the security on individual items for an obscure user interface option.

BPROPFIND

Performing any useful task, such as reading permissions or replica lists.

PROPPATCH

Changing folder properties, including updating permissions, replica lists, or running imports. Used only for wiping item-level permissions. Other code that used this was marked obsolete because of problems.

BCOPY

Used only for folder or item recovery.

BDELETE

Used only for folder or item recovery.

How Rights Translate to Masks

The E2kfdacl.dll version that comes with PFDAVAdmin uses the following method to generate access masks.

  1. Two allow masks are generated, one for folder rights and one for item rights:

    • Create Items: folderMask |= 0x2

    • Read Items: folderMask |= 0x800, itemMask |= 0x1208A9

    • Create Subfolders: folderMask |= 0x4

    • Folder Owner: folderMask |= 0xD4910

    • Folder Contact: folderMask |= 0x8000

    • Folder Visible: folderMask |= 0x1200A9

    • Edit Own: itemMask |= 0x200

    • Edit Any: itemMask |= 0x1E0116

    • Delete Own: itemMask |= 0x400

    • Delete Any: itemMask |= 0x10000

    If, for example, you wanted to build the masks for a Reviewer, you would do the following. A Reviewer has two rights, Read Items and Folder Visible. So, first you build the allow masks:

    • Folder allow: 0x1208A9

    • Item allow: 0x1208A9

    You can see that, for a Reviewer, the allow masks are the same.

  2. Two deny masks are then generated that reflect the opposite of the rights granted. Deny masks are generated where every right not granted is denied:

    • Folder deny: 0xDC916

    • Item deny: 0x1F0716

Note

When an entity is granted Delete Own or Edit Own rights, PFDAVAdmin still builds the masks as described. However, when the store generates masks for those entities, the Delete Own and Edit Own flags are set in the deny mask, even though they are also set in the allow mask. So, in this case, you will notice a difference between the mask generated by using the formula above and the mask returned by the store.

In PFDAVAdmin, you can test the masks generated for a set of rights by using the Folder Permissions option. Set the rights you want on an entity and then use the Current XML button to see the masks generated for that entity.