Every once in a while, a tool comes along that really must form a permanent part of the Exchange professional’s toolkit. One such tool is PFDAVAdmin. Although PFDAVAdmin has been around for a while now, there may be a few people out there who have yet to come across it or maybe need reminding of its existence. PFDAVAdmin is short for the Public Folder Distributed Authoring and Versioning (DAV)-based Administration tool and is written by Bill Long of Microsoft. Back in November 2005, PFDAVAdmin version 2.4 was finally made a supported tool and is now downloadable from the Microsoft downloads website.

Dave Howe of Microsoft PSS in the US first made me aware of this tool a few years ago when it was version 1.6 and, to be honest I should have written this article then. Now when you download the tool from the Microsoft downloads website, you’ll get version 2.7 (at the time of writing this article) which includes the executable, a single DLL file, a useful reference Word document and an end-user license agreement document. For reference, the current build number of PFDAVAdmin at the time of writing this article is 6.05.7869.

One of the original ideas behind PFDAVAdmin was to get Exchange administrators out of the sticky situation they found themselves in after incorrectly altering the permissions on the infamous Exchange 2000 M: drive. For example, if an administrator manually changed public folder permissions within the M: drive via Explorer, the permissions were effectively changed from MAPI canonical to NTFS canonical, meaning that the next time these permissions were modified within Exchange System Manager, an error occurred. I’ll cover more on this type of error later in this article. Of course, similar situations were seen after M: had been scanned by backup or antivirus applications. This was an excellent use of the tool but it didn’t end there, as PFDAVAdmin had other uses such as the propagation of additional access control entries down the public folder tree, or the importing/exporting of folder permissions on mailboxes and public folders.

At the time I received version 1.6 from PSS, I asked if it was widely available. At that stage of the development it wasn’t a supported tool and hence was generally sent out to administrators who had contacted PSS with problems that the tool could resolve. A few years on and a few versions later, PFDAVAdmin is now freely available for download and fully supported by Microsoft. Let’s have a look at what it is capable of after noting the requirements for running it.

The computer that runs PFDAVAdmin must be running Windows XP, Windows 2000 or Windows 2003. Additionally, it must have Exchange 2000 System Manager or Exchange 2003 System Manager installed onto it and must also have the .NET Framework 1.1 installed. The .NET Framework 1.1 is installed automatically on Exchange 2003 servers but is one to watch for if you’re still running Exchange 2000.

So exactly what can PFDAVAdmin do for you? Well, it has a number of capabilities as described within the accompanying Word document, a sample of which is:

• Propagate public folder Access Control Entry (ACE) additions, removals and modifications without overwriting the existing Access Control List (ACL).
• Rectify damaged Discretionary Access Control Lists (DACL).
• Import or export permissions against either mailboxes or public folders.
• Import or export public folder replica lists.
• Set Calendar folder permissions in bulk.

Across this two-part article I’ll take a look at five different uses of PFDAVAdmin. I don’t have the space within this article to cover all of the capabilities of this tool; the accompanying Word document you get when you download the tool explains other features in detail but hopefully you’ll get a feel for what it can do by working through the examples in the two parts of this article.

One common administrative task within the Exchange world is assigning permissions on a public folder from within Exchange System Manager. This can be done by navigating the public folder tree to find the relevant public folder, bringing up its properties, clicking on the Permissions tab and then clicking the Client Permissions button. Here you can add and remove users and set their relevant permissions level. However, have you ever attempted to set public folder permissions only to be greeted by the error shown in Figure 1?

Figure 1: Invalid Window Handle Error

As I said earlier, one of the original ideas behind PFDAVAdmin was to solve this particular problem and although it can now do a whole lot more for you, it’s still important to understand how to solve such permission problems should you see them. In fact, should you suspect any folder permission issues at all, use PFDAVAdmin as your sanity check. Here’s how to do just that in our public folder example.

1. Run PFDAVAdmin.exe
2. At the main PFDAVAdmin window, select File / Connect and in the Connect window, specify the name of the Exchange server and global catalog server to connect to. Also, you’ll need to ensure you can successfully authenticate either via the currently logged-on user or via other credentials. Finally, make sure that the Connection option is set to Public Folders before clicking OK. This window is shown in Figure 2.

Figure 2: Server Connection Window

1. All public folders will then be displayed in the left-hand pane of the main PFDAVAdmin window. In the left-hand pane, expand Public Folders and then find your problematic public folder.
2. Right-click your problematic public folder and choose Folder Permissions from the context menu. You will then be presented with the Permissions window for that public folder, as shown in Figure 3.

Figure 3: Public Folder Permissions Window – Bad DACL

1. What you will notice from this window is that it presents information that is pretty much the same as that which you will see when you click the Client Permissions button on a public folder’s properties from within Exchange System Manager. You can see the folder name in the top left-hand corner of the window, and underneath the permissions assigned to this folder. Note that the Everyone name that you see in Figure 3 corresponds to the Default role seen within the public folder permissions window in Exchange System Manager or Outlook, whilst the NT AUTHORITY\ANONYMOUS LOGON name corresponds to the Anonymous role.
2. The key piece of information presented is the DACL state information highlighted in red in the top-right hand corner of the window. Normally, this should read as Good, but you can see that in our example it reads as Non-canonical order. This means that the access control entries are no longer in Exchange canonical order, a situation that can occur when permissions are modified via Explorer as I said earlier in this article. Additionally, it may be that permissions were altered in some way by another tool. Either way, anything other than Good in the DACL state field is, funnily enough, not good.
3. Fortunately, we can easily fix this problem with PFDAVAdmin. Notice the check box titled Force canonical order and valid masks. Ensuring that this remains selected, all you need to do is to click the Commit changes button. There is also the Wipe existing DACL before committing check box, which literally does what it says: an empty DACL is written first before the permissions are written. This can also be selected when troubleshooting permission problems if required.
4. Clicking the Commit Changes button causes the Permissions window to disappear after the changes have been made. Re-selecting the folder permissions option from the context menu brings up the Permissions window once again, where we can now see that the DACL state information reads as Good, as shown in Figure 4.

Figure 4: Public Folder Permissions Window – Good DACL

Now that we’ve got our public folder permissions configured correctly, let’s look at a simple way of exporting the permissions list for safe keeping. This could be extremely useful if someone else was to alter the permissions list in some way.

1. Run PFDAVAdmin.
2. Select File / Connect and in the Connect window, specify the name of the Exchange server and global catalog server to connect to. Make sure that the Connection option is set to Public Folders before clicking OK.
3. Select Tools / Options and in the PFDAVAdmin Options window, select the Enable logging to file option and check that the location to store the log files is acceptable. Once you’re happy, click OK.
4. Back at the main PFDAVAdmin window, click Tools / Export Permissions. This will bring up the PFDAVAdmin Export Options window as shown in Figure 5. You will see that I’ve selected to export all public folder permissions in Account name format. This means that later, when permissions need to be altered, the resulting output file can only be re-imported into PFDAVAdmin and not other programs. Use the legacyExchangeDN format if you want to use other tools like PFAdmin to import the output file. Note that the XML format will, when imported back in, overwrite the existing permissions rather than appending to them as in the case of the other two formats.

Figure 5: Export Options

1. Click OK and select an output file name. A process window then appears showing you PFDAVAdmin’s progress through the public folder tree. That’s it. The output file can then be used to import the permissions back into the public folder tree via the Tools / Import option within PFDAVAdmin. A sample output file is shown below in Figure 6. I’ve set Notepad’s Word Wrap feature to make the contents fully visible.

Figure 6: Export Format

In part one of this two-part article, I’ve shown you two uses of PFDAVAdmin. In part two, I’ll show you how you can use this tool to centrally set Calendar permissions, something that is an extremely useful thing to do in a lot of organizations. Additionally, I’ll show you how you use can PFDAVAdmin to propagate public folder permissions and manage public folder replicas.