It’s hard to believe that it has been almost 2 years since we first architected the Public Folder sync as an ancillary offering to our Priasoft Migration Suite.  Back then, it was an urgent issue that a customer encountered, which 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 the migration world.  More importantly, this feature would take the laborious process of migrating public folders 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.  This evolutionary process was recently experienced when we decided to support one of the more complex preparatory aspects of Public Folder synchronization during the 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 gigabytes in size, you could have a single Public Folder Mailbox of that size, or two 200 gigabyte mailboxes, or four 100 gigabyte mailboxes and so on.  Again, 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 roll-out, 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: 1.    Analyze the source folders and gather statistics 2.    Find the larger folders and assign them to a specific mailbox 3.    Add more mailboxes as necessary These recommendations were well received, as the feedback was always positive and grateful for exposing something that, on their own, the customer 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 set-up 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’s 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 all, if not most. 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 folders 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 the card analogy would be – but 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 took a few tries to get right.  The next set of complication came from doing several “limit checks” to make sure that no rules were broken with regards to max size, or 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 continue to follow our Priasoft moniker with the 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.

Ready to get started?

Register now for a free evaluation of Priasoft’s Public Folder Migration and Synchronization Manager for Exchange. (Part of the Priasoft Migration Suite for Exchange)

[dt_button url=”https://www.priasoft.com/get-started/pmse-trial-download/” style=”color-primary” size=”btn-lg” skin=”dark” target=”_self”]Download free trial[/dt_button]