Planning for Public Folders in Exchange 2013

When designing for a migration to Exchange Server 2013, chances are you’ll have to deal with public folders. Given that Exchange 2013 has been around for a while, you might think such a task would be a proverbial walk in the park. Of course, if you are looking at a cookie-cutter environment, you might be right. However, in every design there are elements specific to the customer that require a different approach.

More specifically, consider the scenario in which you have public folders — possibly lots of them. For the sake of this article, let’s assume you have about 500GB worth in public folders spread over several thousand public folders across one or more replicas. For some customers, these numbers are much more than they have. For other customers, 500GB in public folders might just be a fraction of what they have to deal with. Regardless of your situation, public folders raise a rather interesting question: How do you plan for (a migration of) public folders to Exchange 2013?

In previous versions of Exchange, public folders 'lived’ in their own database. Public folder databases do not partake in the high-availability features available to regular mailboxes. For instance, a public folder database cannot be part of a DAG, and it relies on its own replication mechanism to replicate data across multiple public folder databases (if configured).

Fast-forward to Exchange 2013, and public folders are now stored in public folder mailboxes, which are hosted in regular mailbox databases. As such, public folder mailboxes now take advantage of the DAG and its replication mechanism. But this also poses another challenge: How do you calculate server role requirements for 500GB in public folders?

In the scenario outlined earlier, some public folders were replicated to another database, while some weren't. Let's consider that the net result is about 400GB in unique public folders in the environment. This means about 25% of the public folders are replicated to other public folder databases; this could be for regional availability purposes or some form of HA. In the new architecture model, however, Microsoft recommends the Preferred Architecture (PA), which dictates there should be four copies of a mailbox database including one lagged copy. If we apply this logic to the 400GB in public folders, this now means the required disk space grew from 500GB to 1.6TB (4x 400GB), which is a whopping 300% increase, just by migrating from an earlier version of Exchange to Exchange 2013! 

But that's not all. When migrating content over to Exchange 2013, you will notice that the reported size of the data will grow by a significant percentage. The actual percentage will vary from customer to customer. But it's not a bad idea to account for a 40% increase in size. This increase only applies to the reported size of items; the actual size on disk will remain the same. Nevertheless, it is important to keep that in mind because it affects things like quotas. In theory, this means the 400GB of public folder data could end up being a little over 600GB that you have to plan for. 

Going back to the numbers, one might say that 1.6TB isn't all that much. That becomes 2.4TB if you include the increase of the reported size. To be honest, if you are deploying on physical hardware, that is likely true. After all, 4TB drivers are commonly available, and most mainstream servers have room for several such disks.

Unfortunately, not every customer deploys physical hardware, and some are required to utilize prior investments in a virtual environment. Given that sizing for Exchange in a virtualized environment should be treated no differently from a physical environment, this means you are now using an additional 1.1 TB on the SAN without taking into account the increase mentioned earlier.

But what if you don't need four copies of your public folder data? What if the availability of the public folder data isn't critical? In such cases, you could, for instance, create separate mailbox databases that are solely used for hosting Public Folder mailboxes. You can then opt to limit the amount of additional copies to one or two instead of three. This allows you to more granularly control how public folders are dealt with in the DAG. Regardless of the approach, it is highly recommended to have at least one extra copy of the database that has the primary public folder. But as a general rule of thumb, it's probably a better idea to have at least one additional copy for all public folder data.

But how do you figure out how much disk space and resources (IOPS) to allocate for those public folders? Unfortunately, the answer is not that simple. For starters, the role requirements calculator does not have a section dedicated to public folders. In fact, there is no mention of public folders at all. So how do you go about it? I asked around in the community to see how other people were dealing with this situation and got various answers.

Unless you are in a very specific scenario and you have a fairly large hierarchy, Microsoft suggests not taking the above approach where you host public folder mailboxes in a separate database. Because the interpretation of large is not set in stone (and Microsoft has not released any numbers that define large), it might be wise to request a second opinion or call in Microsoft support to get an expert’s opinion when you think you are dealing with such a case.

In all other scenarios, Microsoft recommends to "sprinkle" public folder mailboxes across the mailbox databases, just as if they were regular mailboxes. To determine how much disk space you have to assign to them, you could use the server role requirements calculator and dedicate one of the user tiers to public folders. For instance, if you know you have about 400GB in public folders and you don't want to have mailbox sizes exceed 50GB, then you know you’ll need at least 8 mailboxes with a maximum size of 50GB. Because you don't want to forget to account for some growth and overhead, assigning 10 mailboxes of 50GB seems like a good approach:

In the above screenshot, the average message size and messages sent/received per day are based on the average user profile in the environment. However, in many environments, public folders are fairly static. This means the usage profile might be much different (and, as a result, have an impact on the IOPS profile of the public folders).

Determining the usage profile of public folders can be a little tricky! You have to determine how many messages the public folders receive or the (average) size of those messages — both of which you can determine through the Message Tracking Logs. The harder part is to determine how many messages are copied into the public folders (on average); those statistics aren't kept by default. Reporting solutions, such as Mailscape, can help you figure some of the statistics and make your life considerably easier!

Once you have determined the usage profile, you can include that information into the calculator, which will take that information into account when yielding the server role requirements. You will notice that in many cases, the IOPS profile does not change much because of the public folders — but that's no guarantee. If your public folders are heavily used, it could have the opposite effect.

The best way to illustrate this is through an example. Consider a scenario where you have 500 users with a 100 messages/day profile. If you plan to host a single public folder mailbox with a 1,000 messages/day profile in the same mailbox database, the average user profile across the entire database increases by only 1.79 messages per day to 101.79.

( ( (500 x 100) + (1 x 1,000) ) / 501) – 100) = 1.79

Determining disk and IOPS requirements isn't the only challenge that modern public folders entail. Other limitations apply, too. For instance, you cannot have more than 100 public folder mailboxes. Unlike Office 365, Exchange 2013 does not limit how large a mailbox can be. However, I usually apply the same size limitation when designing an on-premises environment; it makes your life easier IF you ever decide to move to Office 365 afterward. If you do happen to need 100 public folder mailboxes, please take into account that only 99 of them should be used to store data. The primary hierarchy mailbox should not contain data and should not be used to hand out hierarchy to clients.

The information in this article might not apply to each environment. As stated earlier, each design exercise is unique because of the intricacies that accompany each environment. However, the general approach should work for the majority of environments out there.

It’s important to understand that the public folders landscape is quickly changing along with the guidance (or lack thereof) on how to deal with them. The main reason Microsoft hasn't released much information about handling public folders is likely because recommendations it makes today might not be relevant a few months from now. Since RTM, Microsoft has made significant changes to the amount of public folders that are supported, and it [Microsoft] has promised to continue improving performance and scalability. As such, it’s not unreasonable to expect more updates over time. So, for now, keep in mind that this article applies to the current version of Exchange 2013 (Cumulative Update 8, at time of writing) and might change when a new Cumulative Update becomes available!

If you have used a different approach or if you have a different opinion, I would love to hear about it! Feel free to leave a comment.

Cheers,

Michael