Managing Public Folders in Microsoft Exchange Server 2007 - 06 Nov 2007

Executive Summary:

Microsoft shocked some people when it announced that public folders are deprecated in Exchange Server 2007. Although it’s a perfectly valid English term, few people use deprecated in daily conversation. In this case, it means that a feature is on its way out. Microsoft wants to remove public folders from Exchange because the company believes that public folders don’t add enough user value to justify the engineering effort required to maintain them. The official stance is that Microsoft will support public folders until at least 2016, but the writing is on the wall. Let’s explore public folder management in Exchange 2007 and what changes you can expect in Exchange 2007 SP1.

If you manage an Exchange Server organization that’s been around for a while, you probably have a love-hate relationship with public folders. On the one hand, public folders store a lot of data, some of which might even be useful. On the other hand, in recent years Microsoft hasn't dedicated much effort to providing tools to manage public folders, so it’s difficult to know exactly who's creating the folders and what they're used for. When Microsoft introduced Exchange Server 4.0 in 1996, public folders let Microsoft compete with the Lotus Notes ability to replicate data so that users could work with a local copy instead of being forced to make a network connection to a remote server—something that was important in the days when network bandwidth wasn’t as available as it is now.

The promise of public folders was that you could build mission-critical applications containing your most important data and Exchange would take care of replicating the data and application logic (i.e., forms) around the Exchange organization. Today, better networks and new applications such as SharePoint have largely removed the need for public folders. However, administrators still have to grapple with the legacy of public folders that users have created and populated over the years.

What's Been Lost
In previous versions of Exchange, you managed public folders through the GUI. The first effect of deprecation is that Exchange 2007 doesn't include options in its Exchange Management Console GUI for managing public folders; they can be managed only with Windows PowerShell commands through Exchange Management Shell. OWA 2007 doesn’t support access to public folders, and you can no longer access public folders through IMAP clients such as Microsoft Outlook Express. With Exchange 2007, if you use Microsoft Office Outlook 2007, you don't need public folders to store system objects such as the Offline Address Book (OAB). If you support any older clients, you still need to deploy system folders because these clients must connect to an Exchange server and open a system folder to access the OAB and other system information.

The lack of an administrative GUI for public folders is a big problem for administrators, but my experience is that the lack of client access to public folders is one of the biggest stumbling blocks to early deployment of Exchange 2007. It therefore comes as no surprise that client support and an administrative GUI for public folders will reappear in Exchange 2007 SP1.

PowerShell is pervasive across all parts of Exchange 2007. Microsoft built the business logic for Exchange into a set of more than 360 commands that serve as the foundation for Exchange Management Console. Anything you can do in the console, you can do with PowerShell—but there are many things you can do only with PowerShell, such as managing public folders.

Looking at Public Folders with PowerShell
Describing in detail each of the commands available to manage public folders would fill a book; I have room here to sketch them only in outline. Like all PowerShell commands, those that work with public folders follow the verb-noun-name-argument structure. For example, in the command

Get-PublicFolder -Identity ` 'Exchange 2007Administration'

Get is the verb, PublicFolder is the noun, -Identity is the name (or parameter), and the argument to the parameter is the string enclosed in single quotation marks. Note that the backtick (`) at the end of the first line indicates that the command continues on the next line; in Exchange Management Shell, you could enter the command on one line without the backtick. In this example, the command returns the properties of the public folder called Administration under the Exchange 2007 folder under the root folder.

You can navigate down through the folder hierarchy by separating each level with a backslash. For example, this command retrieves details of a folder that is four levels deep:

Get-PublicFolder ` -id 'SoftwareExchange 2007' ` + 'ClientsOutlook 2007'

Note that -id is a built-in alias (i.e., shortened form) of the -identity parameter. Also, this example shows the concatenation procedure to use when you have to break a string. On the surface, this example might look complex, and there's no doubt that when you query folders that are many levels down, the argument is a tad long. Nonetheless, the syntax is straightforward and consistent. When you get used to PowerShell's public folder commands, you'll find they flow logically.

If you know the name of a folder, you can ask Exchange to retrieve information about all the folders underneath it by specifying the -Recurse parameter. Figure 1 shows sample output from the following command:

Get-PublicFolder ` -id 'SoftwareExchange 2007' ` -Recurse

If you don’t know the exact name of a public folder, you can have Exchange search for it by piping the output from Get-PublicFolder to a filter applied with the Where-Object cmdlet. This command starts from the root folder (indicated by the backslash) and works its way down:

Get-PublicFolder ` -id  -Recurse | ` Where-Object {$_.Name -eq 'Clients'}

Fortunately, the query operates against the local copy of the public folder hierarchy, but it still won't complete quickly if you have a hierarchy that is many levels deep and contains thousands of folders.

Creating a Public Folder Database
The Exchange 2007 installation program creates a public folder database only if you specify that you want to support Messaging API (MAPI) clients older than Outlook 2007. After installation, if you need to add a public folder database on a server to support local folder replicas, you can create one with the New-PublicFolderDatabase cmdlet. For example, the command

New-PublicFolderDatabase ` 'Public Folders' -StorageGroup ` 'First Storage Group'

creates a new database and puts it into the default storage group (SG). You can choose another SG on the server, but not one that's enabled for local continuous replication. LCR doesn’t support log shipping for public folder databases; Microsoft considers the public folder replication mechanism sufficient for providing resiliency for the folders' content.

You can use the Get-PublicFolderDatabase cmdlet to verify that Exchange created the new database successfully. Specify the -IncludePreExchange2007 parameter to ask Exchange to return a list of all public folder databases in the organization, including those that run on Exchange Server 2003 and Exchange 2000 Server servers:

Get-PublicFolderDatabase ` -IncludePreExchange2007 

To see details of a specific public folder database, you pass the identity of the database to the Get-PublicFolderDatabase cmdlet, including the server name if the name of the database isn't unique. Piping the output to the Format-List cmdlet makes it easier to see all the properties of the database. You can also pipe any PowerShell command to a text file if you want to browse the information at leisure. The complete command is therefore

Get-PublicFolderDatabase ` -id 'ExchSvrPF1Public Folders' ` | Format-List > C:TempPF.Txt

Creating and Removing Public Folders
With a database in place, you can populate it with public folders. The following command uses the New-PublicFolder cmdlet to create a public folder called Exchange 2007 Operations under the Operational Procedures root folder:

New-PublicFolder ` 'Exchange 2007 Operations' ` -Path ' Operational Procedures' ` -Server 'ExchPFSvr1' 

You can remove unwanted public folders with the Remove-PublicFolder cmdlet:

Remove-PublicFolder ` -id 'Exchange 2007Bad Content'

If the specified folder has child folders, this command won’t work and PowerShell generates an error message. In that case, you would need to specify the -Recurse parameter if you want Exchange to remove everything in the folder hierarchy from the folder you specify on down:

Remove-PublicFolder ` -id 'Exchange 2007Bad Content' ` -Recurse

Be sure that none of the affected folders contain useful content before you remove them.

Managing Public Folder Properties
When you create a public folder, it isn't mail-enabled; therefore, you can’t send email to it. If you want to use a public folder to archive discussions between members of a Distribution Group (DG), you need to mail-enable the folder first with the Enable-MailPublicFolder cmdlet. For example,

Enable-MailPublicFolder ` 'Exchange 2007Clients' 

creates an email address for the public folder called Clients. After Exchange mail-enables the public folder, you can check the email address with the Get-MailPublicFolder cmdlet. (The Get-PublicFolder cmdlet doesn't return mail properties.) You can also use Get-MailPublicFolder to retrieve a complete list of mail-enabled public folders and their email addresses by entering the following command:

Get-MailPublicFolder | ` Select Name, PrimarySmtpAddress

The Disable-MailPublicFolder cmdlet removes an email address from a public folder.

When you mail-enable a public folder, it appears in the Global Address List (GAL) along with other mail-enabled objects such as mailboxes and contacts. You can remove the folder from the GAL by setting its HiddenFromAddressListsEnabled property:

Set-PublicFolder -id ' Exchange 2007 Clients' ` -HiddenFromAddressListsEnabled $True

Users can still post to the folder by using the folder’s SMTP address.

The Set-PublicFolder cmdlet manipulates the quota properties of folders. Use the following command so that users don’t treat a public folder as a convenient dumping ground for large files:

Set-PublicFolder ` -id 'Exchange 2007Clients' ` -StorageQuota 990MB ` -PostStorageQuota 1GB ` -MaxItemSize 10MB

The StorageQuota property specifies when Exchange starts issuing warnings that the folder is nearly full; the PostStorageQuota property specifies when Exchange stops accepting new content for the folder; and the MaxItemSize property sets the maximum size for a single item.

Permissions and Accessing Folder Contents
Users can't add content to a public folder unless they have the necessary permission. Exchange provides the Add-PublicFolderClientPermission cmdlet to set permissions on folders. For example, let’s say I want to let the members of the “Exchange Gurus” DG post new content to the Clients public folder. The command to use is

Add-PublicFolderClientPermission ` -id 'Exchange 2007Clients' ` -AccessRights 'Contributor' ` -User 'Exchange Gurus' 

You can check permissions on a folder with the Get-PublicFolderClientPermission command:

Get-PublicFolderClientPermission ` -id 'Exchange2007Clients'

Not surprisingly, you remove permissions with the Remove-PublicFolderClientPermission cmdlet. Microsoft also provides the Set-PublicFolderAdministrativePermission, Get-PublicFolderAdministrativePermission, and Remove-PublicFolderAdministrativePermission cmdlets to let users perform management tasks such as creating new replicas or amending client permissions. For example, to give the user John Smith full administrative permissions over the Clients public folder, we use this command:

Add-PublicFolderAdministrativePermission ` -User 'John Smith' ` -id 'Exchange 2007Clients' ` -AccessRights AllExtendedRights

The PowerShell commands available in Exchange 2007 won't let you add content to public folders, so you have to use clients such as Microsoft Outlook to post items to folders. You can get an idea of what content you have in public folders with the Get-PublicFolderStatistics cmdlet, which returns a variety of statistical data. To get a list of public folders, the number of items in each folder, and the total size of the items in bytes, use the following command:

Get-PublicFolderStatistics | ` Select Name, ItemCount, TotalItemSize 

Get-PublicFolderStatistics can output a lot of information for any reasonably sized public folder hierarchy, so it’s a good idea to pipe the results to a text file.

Public Folders in Exchange 2007 SP1
Microsoft spent a lot of time redesigning Exchange Management Console for Exchange 2007, concentrating on the tasks that Exchange administrators spend most of their time doing. Because not every Exchange administrator needs to manage public folders, it makes sense to move them to the side. However, Exchange organizations that have public folders can’t simply drop them, and not everyone wants to manage public folders through PowerShell. Even though the command-line interface is flexible, it takes time for administrators to master its idiosyncrasies, and time is a precious commodity. Much to everyone’s relief, Microsoft reintroduces a GUI for public folder management in Exchange 2007 SP1, currently in beta and expected to ship in late 2007. The new public folder management option is in the Exchange Management Console Toolbox along with utilities such as the Database Troubleshooter and Mail Flow Troubleshooter. When you choose Public Folder Management, Exchange launches a separate Microsoft Management Console (MMC) instance, as Figure 2 shows .

Exchange 2007 SP1's Public Folder Management Console covers the basics, such as creating and viewing public folders, but not much else. You won't find options to help you migrate public folders to something such as SharePoint, for instance, or even reporting capabilities that might help you understand the public folders that exist and how they're being used. For that information, you have to look to standalone utilities such as the Exchange Server Public Folder Distributed Authoring and Versioning (DAV)-based Administration tool (PFDAVAdmin), which Microsoft has upgraded to work with Exchange 2007. PFDAVAdmin, which you can download at www.microsoft.com/downloads/details.aspx?FamilyID=635BE792-D8AD-49E3-ADA4-E2422C0AB424, provides basic reporting and analysis capabilities to help you understand the structure and usage of public folders. You still have to figure out what specific information is important, whether or not an application (forms-based or otherwise) depends on the data, and what kind of platform might best serve to replace public folders in the future. Third-party vendors are working in this area, and you can expect to see them produce software to help Exchange administrators deal with public folder contents, structure, and migration more comprehensively.

Help with Public Folders
To help you get going with public folder management through PowerShell, Microsoft provides a set of sample scripts, which you can find on an Exchange 2007 server in C:Program FilesMicrosoftExchange ServerScripts. Table 1 lists the names of the scripts and a brief explanation of their purpose.

Let's face it: Public folders are on life support. The only questions are when you'll stop using them and what application or repository you'll use to replace public folders. Exchange 2007 SP1 brings a new GUI interface for public folder management that covers the basics but doesn’t help you plan for a replacement for public folders. Because there has been a general lack of utilities devoted to public folder management, managing these folders has never been easy. PowerShell introduces some new flexibility and capabilities for working with public folders—but to fully realize the benefits, you need to take the time to master the commands.