RSMUS.comWhat else can you compare public folders to but roaches? No Exchange Administrator wants them around, any time you mention them you most likely have a problem with them, and they probably invaded during previous ownership, and have been there for a long time.
Public folders in Exchange Server 2013 present multiple problems. Some contain important files that are still in use, some are invariably empty, and some contain files and items that need to be preserved for compliance purposes. So why not just keep them? Well for starters they have been a stagnated feature in Exchange since the 2003 version. The ability to run Public Folders in a modern Database Availability Group is little consolation. Microsoft only reluctantly included support for them in Exchange 2013. Management is also a consideration. Setting correct permissions on them is finicky at best, they are locked in the database they are in, and cannot be moved around freely like other mail enabled items, and they seem to multiply relentlessly. There is also something to be said for the fact that Microsoft officially decommissioned its last internal Public Folder last October. Their reason to move away from them was the same as yours, the advancement in other technologies. Public Folders were originally meant to “Enhance group collaboration applications like discussion and tracking” as Brian Valentine the then GM for Exchange stated when they first announced them internally in Redmond. We have much better options for that purpose now, which are built with interoperability in mind.
All these things combine to make for a daunting task for an Exchange Administrator looking to migrate to a newer version of Exchange. A question I hear in every Exchange project we undertake is “How do we get rid of them?” No worries, experienced RSM Engineers can help.
We start by discussing your requirements, and then talk about your options. In most cases it comes down to one of three options. For this post we will assume that there is already an on premise Exchange Deployment, and the decision has already been made to not move in to an Office 365 environment.
- You can migrate your Public Folders to your new environment. Microsoft has a procedure for this. It works great in a demo environment. Unfortunately in practice it is a painfully manual process, and it still leaves you with your roaches….you just moved them in to your new house. I have yet to see an environment where I would recommend this.
- Migrate your folders to .pst files, and create shared and resource mailboxes, then import your data. This is a viable option for most, it allows the separate folders to move to manageable mailboxes. You can also store the .pst’s for any retention purposes. This allows you to decide on each folder if you want it back in a production mailbox, or to just keep it around in case someone asks for it.
- Move your Public Folders into SharePoint site Mailboxes. This allows you to take advantage of a myriad of new collaboration options. In most cases this is the best option. It will integrate into your existing SharePoint deployment easily.
Which path is best for my environment? What are some of the specific challenges our environment will present? What new functionalities/technologies can we also leverage as a result of a migration? These are all questions we can help you answer. When you have a cockroach problem, you call an exterminator, if you have a Public Folder problem, call us at 800.274.3978.
