It’s hard to believe that it has been almost two years since we first architected the Public Folder sync as an ancillary offering to our Priasoft Migration Suite. Back then, it was in answer to an urgent issue that a customer encountered and that we quickly committed to resolve. As an ever-present 20-year veteran in the world of how complex migrating Microsoft Exchange can be, we never imagined that our new solution would redefine a facet of the migration world--or that this feature would take the migration of Public Folders from laborious process to migration simplicity. Since then, we’ve continued to refine the solution based on customer experience and feedback, and by taking a forward-looking approach to how the challenges can be solved. We went through this evolutionary again when we decided to support one of the more complex preparatory aspects of Public Folder synchronization during migration.
When Microsoft first changed the storage architecture of Public Folders, it seemed to be a well-timed and necessary change to a system that had been virtually the same for almost 15 years. They first introduced an immediate change in architecture which was the use of mailbox objects for the storage of Public Folder data instead of a single database, which allowed IT administrators to plan for resiliency and recovery in the same manner they would plan for normal mailboxes. And while this change may seem inconsequential to the IT novice, seemingly overnight this shift enabled backups of Public Folder data to be efficiently segmented, making the days of the “2 terabyte data file” a thing of the past. For earlier on-premises deployments of Microsoft Exchange, this change in architecture had an immediately positive impact. But for those customers migrating to later versions of Microsoft Exchange or Office 365, this presented a whole new set of migration considerations and factors that needed addressing before their expedient shift to the Microsoft Cloud. Now, let’s review why.
The new architecture found in Microsoft Exchange 2013 or later, including Office 365, requires the creation of one or more special mailbox objects - Public Folder Mailboxes - to contain the Public Folder information. In an on-premises deployment, this is a fairly easy task since an administrator or Microsoft Exchange architect could choose to set very high size limits on these special mailboxes, or none at all. If you had a Public Folder Database in your source environment that was 400 GB in size, you could have a single Public Folder Mailbox of that size, or two 200 GB mailboxes, or four 100 GB mailboxes, and so on. Again, this is a fairly easy issue to solve, and, as the administrator, you would just do what felt natural or necessary.
However, with Office 365 (cloud computing, anyone?) and the many limits and restrictions it imposes, a scenario like the previous on-premises setup becomes much more arduous. In its early rollout, Microsoft Office 365 was based on Exchange 2010, which used the Public Folder database architecture. Then, when the service transitioned to Exchange 2013 and 2016 as a base platform, different limits were required, some of which were simply the inherited structural limits of a mailbox.
One of the biggest headaches with the use of Public Folder Mailboxes in relation to a migration was how to plan and distribute a large monolithic database of Public Folders data across several smaller mailbox objects. We would often be the first to introduce this headache to our customers and would provide the recipe as to how a customer should tackle the issue, but it was not until very recently that we actually addressed the issue with technology. Resolving the dilemma seemed simple, and we defined three steps for customers to consider at kick start:
- Analyze the source folders and gather statistics.
- Find the larger folders and assign them to a specific mailbox.
- Add more mailboxes as necessary.
These recommendations were well received: The feedback was always positive, and customers were grateful that we exposed something that, on their own, they would not have known. Yet, we knew this was going be just part of a recurring issue that would continue to come up with customers choosing to move to the Microsoft cloud.
The First Sync
In time, and after many customer support calls that were not product-specific in nature but were setup- and preparation-related, we came to the realization that not only had our support burden skyrocketed, but most of the calls were education of deep technical topics. Most customers didn’t even know of the challenge in front of them and the complexity behind it. As such, our support conversations became more about the broader task of migrating to Office 365, and educating customers about issues that they would likely run into and how they, the customer, could tackle those challenges.
Realizing that this could be a substantial burden on customers, what would any good Expert in Microsoft Migrations do? I know, I know--there are a ton of “so called” experts, but after 20 years in the game, we tackle such issues by writing code and creating tools and solutions. However, before you can throw code at it, you must take yourself down the rabbit hole, flush out the anomalies, and define a recipe for success that will work for most, if not all.
As the primary architect of this new build, I was immediately faced with taking myself through the process that our many partners and customers were facing--specifically, how to choose which folders go to which mailbox, and what percentage of a mailbox should be filled up before moving on to another one. What seemed like a simple discussion point, at least conceptually, turned out to be very complicated when it came time to actually figure it out.
Initially, the idea was to treat this like a card dealer, where an even amount of data would be distributed across one or more Public Folder mailboxes. The distribution of the folders was actually easy, but was horribly inefficient. When assigning a folder to a mailbox, you don’t have to assign every folder individually, and really shouldn’t. You only need to assign the parent folder to the mailbox. Any action to create child folders under that parent would automatically assign those children to the same mailbox as the parent folder.
While the card analogy works, it doesn’t quite represent the issue completely. A better analogy to the issue is with farming and watering of crops.
Here in the southwest, much of the crop irrigation is done by flooding, not sprinklers. Farmers dig small canals and channels to direct water to plots of land that have been planted. In this method, one does not have to water every plant individually (as in card analogy). Rather, one only needs to define where the water should begin its flow. Once the canals are dug, the water will then flood and fill up each field.
This is where the first level of complication came in--how to collapse as many child assignments to as few “primer” folder assignments as possible. It was figured out, but it took a few tries to get right.
The next set of complications came from doing several “limit checks” to make sure that no rules were broken with regard to max size, max item/folder count, etc., and to also not exceed any support limits imposed by Microsoft.
Needless to say, and an update later, we figured it out and can rest assured that we can live up to our Priasoft tagline "Experts in Microsoft Migrations"more than metaphorically. Today, not only do we provide the simplest way to migrate and synchronize Public Folders, but we can stake the claim that we are the only ones doing it properly and, most importantly, intuitively to Microsoft Office 365 or Microsoft Exchange.
For more information on Priasoft and posts by Eriq VanBibber, please visit their website at www.priasoft.com.
As the CTO of Priasoft, Eriq VanBibber guides the company to continuously innovating migrations in practice. With more than 20 years developing and guiding corporate technology principles, 15 of those specifically dedicated to customers in need of improved methods for moving their data, Eriq is a notable migration expert who continuous to be directly involved in the front lines of Microsoft Exchange and Office 365 migrations.
