In the January 2002 Information Storeâ€”the new column that examines Microsoft resource kit tools for Exchange Serverâ€”I introduced you to Pfadmin, a Microsoft BackOffice Resource Kit (BORK) tool that can help you manage Exchange Server 5.5 public folders (see "Pfadmin's Setacl Command," January 2002, InstantDoc ID 23138). I examined the pros and cons of the tool's most popular command: Setacl. Pfadmin's other commandsâ€”Rehome, Setreplicas, Listacl, Listreplicas, and Messageclassesâ€”round out this extremely useful resource kit tool.
You can use Pfadmin's Rehome command to rehome a public folder from one server to another. Rehoming isn't exactly moving, although it has some of the same connotations. When you configure a public folder for replication among several servers, those servers point to the public folder's home server. When you rehome a public folder, you direct the replicating servers to a different home server. The command's syntax is
For example, the command that Figure 1 shows uses the Messaging API (MAPI) profile frodo and rehomes the folder mordor to the server hobbiton.
As I explained in my previous column, the profile variable defines the MAPI profile under which you execute Pfadmin. The profile must be attached to a mailbox with Windows NT Site Admin privileges. The folder variable defines the public folder for which you're running Pfadmin; if the folder name contains a space, you need to surround the name with quotation marksâ€”unless you're running the commands in batch mode (as the Web-exclusive sidebar "Using Pfadmin in Batch Mode," http://www.exchangeadmin .com, InstantDoc ID 23523, explains). To specify a subfolder (i.e., any folder lower than \All Public Folders\ folder), you must use a backslash (e.g., type \subfolder to specify \All Public Folders\folder\ subfolder). Instead of an individual folder, you can specify all to reference all public folders. You can use switches with some Pfadmin commands. (For more information about the available switches and about accessing Pfadmin's Help files, see "Pfadmin's Setacl Command.")
The Rehome process is essentially a onetime replication, equivalent to running the Pfadmin Setreplicas command with only one specified replica. You probably won't use the Rehome command often, but it can be useful when you need a dedicated server for your public folder content or when you're moving your Exchange installation from one server or set of hardware to another, then removing the first installation. If you have a large Public Folder Store, you can use this command in batch mode. (See the sidebar "Using Pfadmin in Batch Mode" for instructions.) The Rehome command sets that folder's replica list to the server on which you're rehoming the folder, then permanently deletes the previous replica list.
Rehome won't work when the source and destination servers aren't available on the same network (e.g., when either server is available only through a dial-up connection). In such situations, you need to move all the public folders into a Personal Folders (.pst) file, delete the public folders, allow time for replication, recreate the public folders on the destination server, and copy the data into the new public folders.
The Setreplicas command creates multiple public-folder replicas across your enterprise. The command's syntax is
<server(s)> \[<option> <server(s)>\]... \[yes|no\]
For example, the command that Figure 2 shows uses the MAPI profile frodo and adds a replica of the folder gollum's contacts to the server hobbiton. For the option variable, use add to add a server to the replica list, delete to delete a server from the list, or replace to replace the list with a specific server or servers. Use the yes|no parameter to tell Setreplicas whether to apply the changes to the folder's subfolders.
The Setreplicas command is useful when you have multiple servers spread out over several offices and you want users to be able to access public-folder content from a local server rather than from one across the state. The command also comes in handy when you want to create multiple replicas to provide redundancy. When you use the command's syntax properly and set sensible replication schedules, Setreplicas can shorten the amount of time your users need to access public-folder content.
A word of warning, however: When you use the Setreplicas command with the replace option and specify only one server, the command replaces the current replica list for the specified folder or tree and removes the list from all other locations. If you inadvertently use the command in this way and delete all but one replica, you can create a lot of replication traffic and access times will increase.
The Listacl command returns a list of the mailboxes that hold permissions for a folder (and its subfolders, if you specify them) as well as those mailboxes' rights. The command's syntax is
<folder>|all \[o=<*.cmd>\] \[yes|no\]
The command that Figure 3 shows uses the profile bilbo and returns a list of mailboxes that have permissions to the folder bag end. The bracketed letter that appears with each mailbox defines the rights that the mailbox holds for the public folder. (For an explanation of these rights, see "Pfadmin's Setacl Command.")
This command can help you narrow down the search for a user who deleted an important document or figure out why someone who should be able to edit a folder's content can't do so. Public-folder hierarchies can become confusing quickly, and being able to determine rights can be helpful when you need to troubleshoot your public folders. If you want, you can designate a .cmd file that lists the users and permissions you want List-acl to concentrate on, thereby ignoring users or rights you don't want listed.
The Listreplicas command lists a public folder's replicas and the servers on which they reside. The syntax is
listreplicas <folder>|all \[yes|no\]
The command that Figure 4 shows uses the profile bilbo and lists all the public-folder replicas in the site and specifies which servers each replica resides on.
If your organization has a large public-folder tree and users create many new replicas every day, you can use this command to figure out which servers those folders replicate to and how much of your interserver bandwidth public-folder replication is using. Listreplicas also can give you an idea of where all your hard disk space is going. You can plan your replication topology according to which folders are replicating and determine where you have room to squeeze in one more folder. If you have a particularly large public-folder hierarchy, you might want to shunt the command's output to a text file for further perusal.
Messageclasses lets you search a specific folder tree, examine the message class of every message, then write a Comma Separated Value (CSVâ€”.csv) file that contains one line for each examined folder. (Figure 5, page 14, shows an example of such a file.) The syntax is
<folder>|all \[full|i=<*.ini>\] \[o=<*.csv>\] \[homed\] \[yes|no\]
The optional full parameter indicates that you want a list of all message types that Pfadmin finds in the folder. Or you can designate an .ini file that defines the message types you want listed. The .ini file's format is one message-type entry per line, with subtypes preceded by white space:
If you don't use either parameter, the command's default is to list hard-coded message types. The optional o=*.csv parameter instructs Messageclasses to save the output to a specific .csv file. (The default name is msgtypes.csv.) You can use the optional homed parameter to instruct Messageclasses to examine only messages that are homed to the server you're logged on to.
This command can't return filenames, but it's great at finding specific types of filesâ€”for example, that mysterious .avi file hidden in your heavily nested public folders. Single-instance storage might prevent multiple copies of such a file on one server, but you certainly don't want the file replicating across your network every night. I suggest you use this utility at least once a week to look for .avi, .mov, and other file types associated with large, usually nonâ€”work-related files. If you find these sorts of files, you can use Pfadmin's Listacl command to figure out who has rights to the folder, then educate users who've used of a bit too much Store space.
A Few Caveats
Running Pfadmin creates a second public-folder tree in the profile under which you ran the tool. I couldn't discover any ill effects from having this extra tree, but to remove it, you must replace and remove the profile you used to run Pfadmin. As I explained in "Pfadmin's Setacl Command," you must run Setacl from a Microsoft Outlook 98 or Outlook 97 profile. Therefore, if you want to use Pfadmin's Setacl, don't delete an original Outlook 98 or Outlook 97 profile unless you can create a new one.
As I mentioned in my previous column, an Exchange 2000 Server version of Pfadmin is available in the Microsoft Exchange 2000 Server Resource Kit. That version seems to be a bit more user friendly than the BORK version, but a full analysis is outside the scope of this article. (For information about Pfadmin for Exchange 2000, see the Microsoft article "XADM: Exchange 2000 Public Folder Administration Tool" at http://support.microsoft.com/default/ .aspx?scid=kb;en-us;q287110, or look in the Exchange 2000 resource kit.)
To use Pfadmin's full capabilities, you need to use it in conjunction with the Microsoft Exchange Public Folder Information (Pfinfoâ€”pfinfo.exe) tool, which I'll discuss in an upcoming column. (Pfinfo extracts information about an Exchange site's public folders, then saves the information to a file that you can view and manipulate in a spreadsheet such as Microsoft Excel.) In the meantime, if you have any questions about Pfadmin, you can email me at drewski@tech sanctuary.org.