It's not too early to prepare for retirement—of public folders, that is. Eventually public folders will no longer be in Microsoft Exchange. In September 2006, Gartner Research published a report recommending that organizations prepare to migrate away from public folders (http://download.microsoft.com/download/6/D/A/6DA5F58F-5146-4897-8111-DF32896FC1B7/Rapport_Gartner.pdf). But never fear: SharePoint's Microsoft Outlook and Exchange integration features enable administrators to begin the transition away from public folders to using SharePoint as an alternative repository for shared information. In fact, Microsoft has already begun to emphasize SharePoint as its collaboration platform to replace public folders. Although SharePoint isn't a perfect replacement for public folders at all sites, it can ease the transition away from public folders.

Let's peruse some popular public folder features and how they map to the latest SharePoint technology. Some features apply to both Windows SharePoint Services 3.0 (WSS 3.0—a component of Windows Server 2003, providing core SharePoint functionality) and Microsoft Office SharePoint Server 2007 (MOSS 2007—which adds enriched functionality such as enterprise content management); other features apply to MOSS 2007 only.

Outlook Integration
Outlook is for many the primary interface for business communications, and the accessibility of public folders from Outlook has been fundamental to their adoption.

Outlook synchronizes public folder content to the offline folder store (OST), to let users work with mailbox and public folder data while offline. WSS 3.0 provides integration with the Microsoft Office 2007 suite, the Microsoft Office 2003 suite, and Outlook in particular. You can connect SharePoint calendars and contact lists to Microsoft Office Outlook 2003. If you're using Microsoft Office Outlook 2007, you can also connect SharePoint task lists, discussion boards, and document libraries. Other SharePoint items, such as custom lists, custom views, and custom properties are not yet supported.

To connect a SharePoint container to Outlook, use your browser to navigate to the container and select Connect to Outlook from the Action menu.

The first time you connect a SharePoint container to Outlook, Outlook creates a PST file in your Windows profile. The file is named SharePoint Folders.pst for Outlook 2003 and SharePoint Lists.pst for Outlook 2007. A folder is created in the PST file that represents the connected container. Subsequent container connections are represented as additional folders in the PST. Outlook uses its Send/Receive functionality to synchronize content between SharePoint and Outlook. Outlook 2003 provides one-way offline synchronization (SharePoint to Outlook) for calendars and contact lists. Outlook 2007 extends this integration providing two-way offline synchronization for calendars, contacts, tasks, and discussion lists and one-way synchronization (SharePoint to Outlook) for SharePoint document libraries. Although you might not want to move completely over to SharePoint until its offline synchronization improves, if you're using public folders for collaborating on documents, SharePoint is actually a better environment in spite of the one-way synchronization limit.

You can use Office 2007's Edit Offline function to perform manual synchronization of Office documents stored in document libraries. Outlook 2007 keeps track of documents in the SharePoint PST that were modified while you were offline. Office 2007 adds a link to each modified document to the Offline Documents search folder in the PST, providing a single location to track all offline changes. After you're back online, you can open each modified document and save your changes back to the SharePoint server. Office 2007 handles any version conflicts.

Other Office 2007 products such as Microsoft Office Groove 2007 and Microsoft Office Access 2007 provide capabilities such as two-way synchronization between document libraries and custom lists, respectively. (For more information about synchronizing data by using Groove, see the Microsoft Virtual Lab at http://msevents.microsoft.com/cui/webcasteventdetails.aspx?eventid=1032326933&eventcategory=3&culture=enus&countrycode=us; for more information about synchronizing data between SharePoint and Access, see the Microsoft article "Introduction to integrating data between Access and a SharePoint site" at http://office.microsoft.com/en-us/access/ ha101314631033.aspx.) Additionally, third-party products such as Colligo Contributor for SharePoint, from Colligo Networks, provide two-way synchronization of lists, document libraries, and form libraries, including all associated properties and views.

Discussion-Group Integration
You can use Exchange public folders to archive group discussions. Public folders have an associated email address that lets an administrator make the public folder a member of a Distribution Group (DG). All messages sent to the DG are posted to the associated public folder, effectively creating an archive of the discussions emailed to the group. The public folder permissions must allow group members to create new content in the folder; otherwise, attempts to post to the folder will fail.

To replace the public folder functionality, you can create a group in SharePoint that maps to a DG in Active Directory (AD) and to a discussion board in SharePoint. The members added to the SharePoint group are automatically added to the associated DG in AD. The AD DG appears in the Global Address List (GAL), and any messages sent to it are sent to all the DG members and posted to the SharePoint discussion board. The discussion board permissions have to allow DG members to contribute content to the board. The discussion board honors threading from replies, and each post in the archive contains a history of the conversation thread.

This approach is analogous to the public folder approach, especially as you can synchronize the list to Outlook and it's accessible from a Web browser, although the archives go to a different place for the user. Another added benefit is the fact that SharePoint automatically indexes the content stored in the archive and thus the discussions are accessible through the SharePoint Search UI.

An administrator can configure the SharePoint farm to allow incoming email, which means that document libraries, form libraries, and lists can receive content via email messages. When you configure a list or document library to accept incoming email, you can specify whether to retain the original message or only the attachments. If more than one document is attached to the message, SharePoint posts each attachment as an individual item in the document library.

When enabling a SharePoint container to accept email, the user identifies an email address for the container. If the SharePoint Directory Management Service is enabled, a matching contact object is automatically created in the appropriate organizational unit (OU) in AD. Unfortunately, in Microsoft Exchange Server 2003 and Exchange 2000 Server environments, the Directory Management Service doesn't populate all the required attributes for a mail-enabled contact object, causing attachments mailed to the container to be dropped. For more information about dropped email attachments, see "Attachment is missing from an email message that is sent to a Microsoft Windows SharePoint Services 3.0 document library" (http://support.microsoft.com/kb/926891).

Other anomalies exist on the Exchange Server 2007 side in regard to mail-enabled contact creation. For example, although the Directory Management Service relies on the recipient update service to stamp the proxyAddresses attribute, Exchange Server 2007 doesn't which means that objects provisioned by using the Directory Management Service will be incomplete.

Multiple Content Types
Public folders let users store multiple content types in the same folder hierarchy and, in some cases, the same folder. For example, a team can share a set of public folders that store the team calendar, contacts, and project information. The project folder could contain Microsoft Office Project documents, Microsoft Word documents, Microsoft Excel spreadsheets, and email messages. However, public folders are limited in that certain disparate message classes—such as an appointment, a contact, and a mail message—cannot coexist in a single folder.

WSS 3.0 introduces the concept of content types. A content type describes the characteristics of an item in SharePoint, including its properties, workflows, associated document template, and information management policies. For example, you can define a budget content type that has a budget template, a specific set of custom properties, and an approval workflow associated with it. When a user creates an item of that budget content type, he or she creates a budget document from the template, populates the required properties, and saves the document, triggering an approval workflow. SharePoint supports the storage of multiple content types within the same container. SharePoint content types are managed and updated from a central location and can be deployed across an organization to quickly roll out updates to forms or document templates.

The content types assigned to a SharePoint container are available from the container's main menu, making it easy for a user to create an item of a specific type. Together, SharePoint's content-type functionality and the ability to email-enable SharePoint containers provide a repository from which you can initiate a specific workflow or information management policy.

Security
From Outlook, the public folder owner can apply role-based permissions to public folders, granting read, write, and delete access. Using the Exchange Folder Visible permission, you can specify which users see the presence of the folder. This is an important feature from a usability standpoint: It's frustrating to click a folder only to receive an access denied message. Public folder permissions are set on a folder level. If users have access to a folder, they automatically have access to all nonfolder items within that folder. This is where SharePoint has an advantage over Exchange—you can apply role-based security at the item level, letting users see only the items to which they have access, as Figure 1 shows. Although Exchange public folder permissions don't map to SharePoint permissions, you can use the same AD mail-enabled security groups to apply security to both environments. Surprisingly, SharePoint lacks the ability to restrict the creation of subfolders, a security feature many organizations would like to have, and which public folders do offer.

Document Repository
Public folders are a convenient way to share documents that don't change. But because they lack document management functionality, such as version control and conflict resolution, public folders aren't well suited to sharing dynamic content often generated by team collaboration.

WSS 3.0 provides basic document management features, such as major and minor versioning, check-in/checkout, document profiles, workflow, and auditing. MOSS 2007 adds an additional layer of document management capabilities by providing features such as Web content management and publishing, records management, and policy management.

Deleted-Item retention
If you delete a public folder item, and you have full read, write, and delete permissions on the folder, you can use Exchange's deleted item retention feature to recover the content. You configure the Exchange server for deleted item retention, including the length of the retention period, which is when item recovery has to occur.

WSS 3.0 has a two-stage recycle bin, which Figure 2 shows. Each site within a site collection has a recycle bin that's accessible to end users. When users navigate to the site recycle bin, they receive a personalized view of the content they've deleted from the site, referred to as the end-user recycle bin, from which they can recover their deleted content. The second level of deleted-item retention occurs at the site-collection level; the administrator has access to this site-collection recycle bin. This bin tracks content deleted from all sites within the site collection, including content currently listed in the end-user recycle bins. When a user empties the end-user recycle bin, the deleted content disappears from that bin but remains in the site-collection recycle bin. The administrator can change the view of the site-collection recycle bin to display only items that have been deleted from the end-user recycle bin, providing a convenient way to retrieve content for a user. The retention period for items in the recycle bin defaults to 30 days; the administrator can also configure this value.

Extensibility
Some companies have embraced the extensibility of public folders by building applications that leverage custom forms, event sinks, and the workflow engine. Exchange provides the ability to create a custom form and associate it with a public folder. Exchange Web forms, available in Exchange 2003 and Exchange 2000, provide a mechanism for building custom Web pages that override the default Microsoft Outlook Web Access (OWA) public folder rendering, in case you want a custom version for your users. However, Exchange Web Forms have been removed from Exchange 2007. If you require this capability, Microsoft recommends that you use ASP.NET to extract data from Exchange 2007 and render it for Webbased clients.

Exchange 2003 and Exchange 2000 support an event architecture that lets your code trigger when items are saved, modified, deleted, moved, or copied within the Information Store (IS). For example, to send an email notification when a user posts a document to a public folder, you register your code in the public folder to be executed when a save event occurs. Exchange supports synchronous and asynchronous events. Synchronous events let you modify an item before a specific action, such as save or delete, is completed. Asynchronous events let you modify an item after the action is completed.

Exchange 2003 and Exchange 2000 provide a workflow engine that uses event sinks to determine the state of an item involved in a workflow process. Additionally, Exchange 2003 and Exchange 2000 include a scripting technology, Collaboration Data Objects for Workflow (CDOWF), which provides tools for writing and managing Exchange workflows. However, Exchange 2007 doesn't ship with a workflow engine or CDOWF. Microsoft recommends that existing applications based on public folders be left in place on Exchange 2003 servers. Customers who want to migrate their servers to Exchange 2007 should consider porting their Exchange workflow applications to Windows Workflow Foundation. Workflow Foundation is part of Microsoft .NET Framework 3.0 and will be included in Windows Server 2008 (formerly codenamed Longhorn Server). Workflow Foundation provides a runtime engine, a base activity library, and designing tools that run in Microsoft Visual Studio 2005. Companies that have used the more complex features of Exchange and built sophisticated public folder applications should scrutinize the WSS 3.0 and MOSS 2007 feature set to determine whether migration is even an option.

MOSS 2007 offers InfoPath Forms Services, which lets you build XML-based forms and integrate them into your business processes. InfoPath Forms Services provides a server-based runtime environment for Microsoft Office InfoPath 2007 Forms and lets users complete Web-enabled forms by using a browser or an HTML-enabled mobile device. Webenabled forms remove the requirement for the user to install client components in order to update forms.

SharePoint provides a set of synchronous and asynchronous events that you can integrate with lists, document libraries, sites, and even user operations. Workflow Foundation is at the heart of the MOSS 2007 workflow functionality. MOSS 2007 comes with a set of predefined workflow templates for common workflows, such as approval routing and issue tracking. MOSS 2007 workflows can be associated with a document library, list, or content type and can be authored by using the browser, Microsoft Office SharePoint Designer, or VS 2005 and Workflow Foundation. Additionally, MOSS 2007 workflows can leverage InfoPath forms and support Office 2007 client integration, letting you approve a workflow within an Office application such as Outlook.

Replication
One final important feature of public folders is replication, the transfer of data from one public folder server to one or more public folder servers that maintain replicas of designated folders via a series of content-replication messages. The messages keep the source and destination servers synchronized. Replication moves public folder data closer to the end user to improve performance and is valuable where network latency is a problem. Public folder replication is also commonly used to provide redundancy, so that if an outage occurs on one public folder server, the content remains accessible via a replica on another public folder server.

MOSS 2007 doesn't have out-of-the-box replication functionality; however, third-party vendors such as iOra offer products that fit this scenario. iOra Accelerator for SharePoint replicates Web and file-based content to a remote server or an end user's machine.

The Way Forward
You can begin to prepare for the retirement of public folders by assessing how public folders are used in your organization. Questions to answer include the following:

• How many folders are actively being used?

• How many folders are dormant?

• Which folders are mail-enabled?

• What is the security structure of your folder hierarchy?

• Are you replicating folders, and why?

• Where are you using custom forms, event sinks, and workflow?

Several tools help with assessment and migration. Quest Software's MessageStats can help you analyze your public folder infrastructure, and its Public Folder Migrator for SharePoint can help you migrate content from public folders to SharePoint containers. AvePoint's DocAve 4.1 Migrator for SharePoint is another such tool.

If you use public folders as a simple document repository and don't rely on replication, migrating to SharePoint is a natural and relatively straight-forward process. If, however, you use public folders as a document repository with highly complex workflow, custom forms, and event sink routines, Microsoft recommends that you leave them running happily in Exchange. But given that the future of public folders is uncertain, now would be a good time to start investigating redesigning these applications for a more suitable platform such as Microsoft .NET Framework 3.0, taking advantage of WSS 3.0, MOSS 2007, and Exchange 2007 Web Services. Migrating from public folders provides the opportunity for you to assess these new capabilities and determine whether your organization can leverage them.