Public folders provide one way to collaborate and share data, but they're quickly becoming obsolete. SharePoint Portal Server can provide much of the same features in a better manner. Here's why and how to migrate from public folders to SharePoint shares.
If you have installed Service Pack 2 for Microsoft Exchange Server 2003, you might have noticed that there are a few minor enhancements to Exchange public folders. Sadly, public folders are now as good as they are ever going to get. Microsoft has planned a slow death for public folders. The next version of Exchange Server (currently dubbed Exchange 12) will support public folders, but rumor has it that public folder functionality is not going to be enhanced at all beyond what is currently available in Exchange Server 2003. Microsoft is currently planning on eliminating public folders from Exchange 13 though.
Of course Exchange 13 is a long way off. Exchange 12 has only just entered the beta testing phase of its lifecycle. What I can tell you though is that I have heard rumors that Exchange 13 will support public folders that reside on older Exchange Servers within your Exchange organization, but it will not have the capacity to host any public folders on its own.
This brings up the question of what you should do with your existing public folders. At the current time, Microsoft is recommending that public folder contents be migrated to SharePoint Portal Server. In this article, I will walk you through a sample public folder migration.
Time for a reality check
Before I get into all of the technical stuff, I wanted to stop and talk about the practicality of a public folder migration. I haven't seen any official Exchange Server road maps from Microsoft, but my best guess is that Exchange 13 is probably at least four or five years away from being released. Furthermore, as I will explain in more detail later, there are some types of public folders for which no migration solution currently exists. It would therefore be at least a little irresponsible of me if I were to tell you to go out and buy a server to run SharePoint on and to start migrating your public folders ASAP.
If that's the case though, you might be wondering why I am even bothering to write this article now (December 2005) rather than waiting a few years. The reason why I am writing this article right now is because, to be perfectly frank, I've never been a big believer in public folders.
Before I tell you why I have never been a big believer in Exchange public folders, let me just say that I have been working with Exchange Server since version 4. I have worked with a lot of real world Exchange Server deployments, I have passed Microsoft's Exchange Server certification exam, and I am a Microsoft Exchange Server MVP. The point that I am trying to make is that I'm not bashing public folders because I don't understand them. I have worked with public folders extensively, I just don't think that they the best solution in most cases.
The reason why I am saying this is because only about half of the Exchange Server deployments that I have worked with even bother using public folders. Of the organizations that do use them, most use public folders as a file repository or as a way of storing contact information.
I've always thought that the idea of using a public folder as a file repository in this day and age is a bit weird. Typically, when companies use public folders to store files, they will place things like Human Resource forms and company handbooks into public folders. I have even seen one organization use public folders to store Windows security patches. There really isn't anything wrong with storing documents or other types of files in public folders. After all, that's why public folders exist, right? It just seems to me that storing documents in public folders is kind of a dated concept.
At one time there were some advantages to storing commonly used documents in public folders rather than in a normal NTFS folder. Back in the Exchange 4 / Exchange 5 time frame, public folders could potentially make it easier to locate information. The public folders were accessible through Outlook, so they are right there at the user's fingertips. Furthermore, public folders could use descriptive, long file names. Long file names aren't really an issue for us today, but in the Exchange 4 / Exchange 5 time frame, many users were still using Windows 3.1, which didn't support long file names. Placing commonly used files into public folders provided a way of placing document files into folders with descriptive names that were accessible to everyone regardless of operating system.
Another advantage to placing documents into public folders was that public folders are searchable. At the time that Public Folders were first introduced, that was a big deal. The Windows operating system didn't have a built in search feature yet, and SharePoint hadn't even been thought of. If a document was frequently used by users, but was rarely modified, it used to make perfect sense to put it into a public folder.
Why it's a bad idea today
Today though, I tend to think that placing documents into public folders is a bad idea because of the excessive workload that doing so places on the Exchange Server (unless you have a dedicated public folder server). It's true that public folders still allow you to organize data in a meaningful way, and they allow users to easily search for specific data, but in order to make public folder searches half way efficient, you must enable full text indexing. The problem is that full text indexing consumes a significant amount of memory, disk space, and CPU time. If your Exchange Server is already working hard to process inbound and outbound E-mail messages, then the last thing that you probably want to do is to place an additional workload onto the server.
SharePoint Portal Server to the rescue!
This is where SharePoint Portal Server comes in. There are a lot of different things that you can do with SharePoint Portal Server, but one of SharePoint's primary functions is that it can be used to manage an enterprise wide document library. This means that if you were to move all of those documents that are currently sitting in public folders over to a SharePoint document library, you can free up some of the resources on your Exchange Server and take advantage of some document management features that simply don't exist in Exchange Server.
For example, SharePoint Portal Server offers a nicer search feature than the one that you would use for public folders. The SharePoint search engine allows you to search for documents by using things like keywords, date, and author. SharePoint also allows you to maintain multiple versions of a document, and you can even set up approval routing that allow document changes to be reviewed prior to being published, if that is something that interests you.
When it comes to storing and maintaining documents, SharePoint is just a better tool for the job than Exchange public folders are. As I said in the beginning though, you may not be able to move all of your public folders over to SharePoint Portal Server. The reason is because although most public folders are used to store documents, public folders can actually store any variety of Outlook data (calendar items, tasks, journal entries, contacts, etc.). SharePoint Portal Server is very well suited to storing documents, but you will have to use a little imagination for importing other types of data.
As you may know, users access SharePoint through a Web interface, known as a dashboard. The dashboard is made up of a collection of Web parts. A Web part is simply a stand alone Web applet. Out of the box, SharePoint contains a Web part that can be used for storing contacts. At the moment, there really isn't a good way of migrating contacts from a public folder into a SharePoint contact library, but SharePoint does have the capacity to store contacts that are entered manually.
The same thing can be said about public folders containing calendar entries. Web parts exist that allow you to maintain a calendar through SharePoint, but currently no mechanism exists that will allow you to import calendar entries from a public folder. My suggestion is that for right now, you should focus on migrating documents from public folders into a SharePoint document library. I am guessing that future versions of SharePoint will make it much easier to migrate the data from other types of public folders.
Migrating documents from public folders to a SharePoint document library
Now that I have discussed the various philosophies regarding public folder migrations, let's take a look at a technique that you can use for migrating public folders that contain document files. You will have to begin the process by preparing the folders that you plan on migrating. Specifically, this means that you will have to mail enable the folders that you plan on moving, and you will have to set some permissions to make the folders accessible to SharePoint.
Begin by opening the Exchange System Manager and navigating through the console tree to Administrative Groups | your administrative group | Folders | Public Folders | the folder that you plan on migrating. Now, right click on the folder that you plan on migrating and select the All Tasks | Mail Enable commands from the shortcut menus. When you do, Exchange will assign both an X.400 and an SMTP E-mail address to the folder. To view these addresses, right click on the folder and select the Properties command from the resulting shortcut menu. When you do, you will see the folder's properties sheet. Select the properties sheet's E-Mail Addresses tab to reveal the E-mail addresses that have been assigned to the folder.
Once you have confirmed that E-mail addresses have been assigned to the folder, go to the properties sheet's Permissions tab. Click the Client Permissions button and you will see a list of all of the users who currently have permissions to access the folder. At this point, you must click the Add button and add the Windows SharePoint Services Application Pool account to the list of users who have permission to access the folder. You must the assign this account the Reviewer role, which is the equivalent of read permissions.
Now that you have prepared the public folder, it's time to prepare SharePoint. Begin by opening the SharePoint Central Administration console (found on the Administrative Tools menu). When the console opens, click the Configure Virtual Server Settings link found in the console's Virtual Server Configuration section. Next, click on the virtual server that's going to be hosting your SharePoint document library, followed by the Virtual Server General Settings link.
At this point, you will see the console's Virtual Server General Settings page appear. Scroll down to the bottom of the page and locate the E-Mail Enabled Document Libraries section. Within the E-Mail Enabled Document Libraries section, select the Yes option to aloe the document libraries on the virtual server to accept E-mail attachments.
At this point, you must enter the root path to your Exchange Server's public folder library. The root path usually looks like http://servername/public. You must now enter the frequency at which the SharePoint server will check the Exchange server for new posts. Normally, you would want the SharePoint Server to check the Exchange Server on an hourly basis (which is the default) so that the two servers are kept somewhat in sync. However, since you are actually migrating the posts, the frequency doesn't matter as much.
Click OK and it's time to link the document library to the specific public folder that you want to migrate. To do so, go to the document library and click the Modify Settings and Columns link found in the Actions section. You will now be taken to the Customize Document Library screen. At this point, click the Change Advanced Settings link found in the General Settings section. When you do, the Document Library Advanced Settings screen will be displayed.
On this screen, there is a field labeled Public Folder Address. Enter the path to the public folder that you are planning on migrating. You can enter the path in the following format: http://servername/public/root_folder/subfolder. Click OK to complete the process.
Now, SharePoint will periodically check the public folder according to the schedule that you set for any new documents. When documents are found, they are copied to the document library using a unique file name. Once all of the documents have been copied to the document library, break SharePoint's association with the public folder, and verify that all of the documents in the document library still exist. You can then delete the public folder from your Exchange Server, but I recommend waiting a few days just to make sure that everything is working as expected. You can simply change the public folder's permissions to prevent users from posting any new content into it until you are ready to delete the folder.
As I have already explained, there isn't a solution available yet that will migrate all types of public folder data over to SharePoint. I did want to at least mention though that there is a third party migration product that you can use in place of the procedure that I described above. The name of the product is Document Import Kit for SharePoint 2003 (or DocKIT for short). I have never actually used this product before, but it claims to be able to import documents from public folders into SharePoint.