Step 1 – Target Environment Preparation

This task is to prepare the target environment to receive the public folder data with guidelines for supportability and anticipation of future growth and usage.  The Priasoft PF Sync must be able to connect to two public folder environments simultaneously in order to perform its work.  Priasoft supports same-forest, cross-forest, ground-to-cloud, cloud-to-ground, and cloud-to-cloud scenarios.  Legacy-to-modern scenarios are the only support scenario for same-forest environments.  For example, migration from Exchange 2013 to 2016 for public folders is not supported nor is it needed since such scenarios simply involve the use of Exchange’s mailbox move tasks.

The first preparation task is the creation of the primary hierarchy mailbox for public folders if one doesn’t yet exist.  For cases where public folders are already present in the destination no additional preparation is necessary.

Primary Hierarchy Mailbox

The Primary Hierarchy Mailbox – of which there is only ever one – is a special and very important mailbox in the Modern Public Folders system.  This mailbox is the authoritative source of the entire folder hierarchy.  All folder actions such as creation, deletion, rename, movement, and permissions are routed to the Primary Hierarchy Mailbox for execution.  Changes are then queued for distribution to all of the Secondary Hierarchy Mailboxes.  Given its special role, this mailbox should be treated differently with regards to performance, protection, and resiliency.  If this special mailbox corrupts, is deleted, or otherwise becomes unusable then users will have issues with folder related actions.  Microsoft provides no administrator functions or tools to promote a secondary hierarchy mailbox to a primary.  This can only be done (possibly) with Microsoft support.

When creating the first public folder mailbox it will initially be listed as a Secondary Hierarchy Mailbox.  After some seconds or minutes, a refresh should show the mailbox as a Primary Hierarchy Mailbox.  Office 365 can be especially slow in this regard, sometimes taking any where from 15 to 60 minutes before converting to the Primary Hierarchy Mailbox.  Do not proceed with any further steps (in this section or later) until the mailbox is listed as a Primary Hierarchy Mailbox.

In an Office 365 deployment, there’s little that can be done to protect this mailbox and is not as necessary to manage in that way.  The most important concept is to never allow it to be deleted unless all public folder mailboxes are also going to be deleted.

Additionally, if the Exchange Organization config is setup for remote public folders (details exist later in this section) BEFORE the primary hierarchy mailbox is created, any public folder mailbox creation will remain as a secondary hierarchy mailbox.  In such scenarios the following recipe must be followed:

1. Temporarily change the organization config from remote to local public folders
2. Create the first public folder mailbox
3. Wait for the mailbox to appear as a Primary Hierarchy Mailbox
4. Reset the organization config back to remote public folders

Note that during the change currently connected end user could also temporarily lose connections to public folders as Outlook reacts to the organization config change.  Once the change is made back to remote public folders, Outlook will react again to that and remake the connections.  Such a change is best served off-hours and through a change control process.

In a same-forest scenario, this is not as simple.  Microsoft Exchange will not allow for the creation of the Primary Hierarchy mailbox in this scenario.  The first public folder mailbox must be created by PowerShell with the -HoldForMigration flag which subsequently prevents it from becoming the Primary Hierarchy Mailbox.  The Exchange Organization Config has to be edited to force the mailbox to become primary.  This change can only be done by direct manipulation of the Exchange Organization object in Active Directory.  Priasoft support engages with each customer in a live session to explain and show the specific change that must occur.

Consideration and Best Practices

For on-premises environments, the following should be considered before creating the primary hierarchy mailbox:

• The Primary Hierarchy Mailbox should be placed on a mailbox database with no other mailboxes, if possible.  Experience has shown performance problems with public folders if this mailbox is mixed in with user mailboxes or other public folder mailboxes.
• This mailbox should have its max size greatly limited so that it cannot ever reach the 100GB supported maximum.  Priasoft suggests a small between two and five gigabytes.
• Priasoft highly recommends the use of a Database Availability Group and to have multiple copies of the database containing this mailbox.  The use of a disaster recover database is valuable when available are “lag copy” databases.  Priasoft support can discuss these elements with your team when needed.
• Priasoft recommends that all of the public folder mailboxes be in dedicated mailbox databases and not mixed in with user mailboxes.  The maintenance cycle and patter for public folders is often very different than for user mailboxes.  Mixing public folder mailboxes with user mailboxes can mean that when the database is taken offline for maintenance then the public folder contents become unavailable for everyone, not just for the mailboxes affected by the down database.
• If creating a new database for this mailbox, it is recommended that the database settings define the mailbox size and also that the database be placed on a data storage volume that has very low latency.

Additionally, the following should be considered for on-premises environments with regards to secondary hierarchy mailboxes:

• The secondary hierarchy mailboxes will hold the contents of folders.  The term ‘content mailbox’ is synonymous with secondary hierarchy mailbox.
• Microsoft does not support a public folder mailbox greater than 100GB (on-premises and Office 365 have the same limit)
• Priasoft recommends that all secondary hierarchy mailboxes are hosted in dedicated mailbox database and that they are not mixed in with user or shared mailboxes.
• When using a dedicated database, the database should be set so that mailboxes in the database have a max size of 100GB to match the Microsoft support limit.
• A decision should be made as to the max size of database files for public folder databases.  If, for example, the organization prefers that database files not exceed 500GB, then one should not place more than 5-10 mailboxes per database.  The possibility to oversubscribe the mailboxes is acceptable because initially these content mailboxes should have between 20-25GB of initial data at the end of the migration.  Ten mailboxes at 20GB each would be 200GB of initial data leaving 300GB of free space for growth.  Adjust as needed while considering your storage platform, resiliency, backup patterns, and performance.
• The total number of secondary hierarchy mailboxes will be determined in Step #2.  Early forecasting can be done now by planning for 20GB of data per mailbox through the migration.  For example, if there is a total of 1TB of source public folder data, this would equate to minimum of 50 content mailboxes.  Since it is possible for some variance with the initial loading of mailboxes the mathematical derived number should be padded by 1 or 2 additional mailboxes resulting in 51-52 mailboxes should be expected.
• User connections and geographic location should also be considered with regards to database creation.  See below for detail about user connections.

End User Connections

There are two types of public folder connections for Outlook clients.

• Local: Outlook connects to public folders from the same Exchange environment as the user’s mailbox
• Remote:  Outlook connects to public folders in an environment or version that differs from the user’s mailbox.
  • Outlook on Windows has no issues with remote public folders, however, Outlook for MAC is different.
  • Outlook will make a second AutoDiscover request based on the email address of the public folder mailbox value returned in the AutoDiscover response.  It receives public folder connection information from this second response.
  • Only Outlook for MAC 2016 or later has capability to use remote public folders, but real world experience shows that the feature is fragile and doesn’t always work properly.
  • Outlook for MAC cannot connect to Exchange 2010 public folders if the user mailbox resides in Office 365 or in a cross-forest organization.
  • Outlook for Mobile is not able to access public folders an any scenario; the feature just doesn’t exist.
  • Outlook Web Access (OWA) is only able to access LOCAL public folders.  If a mailbox user is set for remote public folders, the user will not be able to access them from OWA.
  • An on-premises Outlook user, regardless of Outlook version or type and regardless of hybrid-mode or not, cannot connect to Office 365 public folders.

The PublicFoldersEnabled property of the Exchange Organization Config (see: Get-OrganizationConfig) determines how Autodiscover returns information about public folders.  When set to LOCAL, Exchange will randomly choose the identity (primary SMTP address) of one of the public folder mailboxes marked as “hierarchy serving” (see: IsExcludedFromServingHierarchy).  When set to REMOTE, Exchange will randomly select one of the mailboxes from the RemotePublicFolderMailboxes list. The RemotePublicFolderMailboxes list is not automatically set with values and must be set at the same time that PublicFoldersEnabled is set to REMOTE.  The RemotePublicFolderMailboxes list can only be populated with identities of mailboxes or mail-users that exist in the same environment as the Organization Config.  This requires either a synchronization of either the source’s public folder mailboxes (modern) or one or more “proxy” mailboxes (legacy) to the target Exchange environment.  The synchronization should create the source mailboxes as mail-users (user with forwarding email address only and no mailbox).  The email address of the mail-user must be a value for which Autodiscover would only resolve to the source environment.

The random assignment only occurs if the mailbox for which AutoDiscover information is requested has a null value for the mailbox property DefaultPublicFolderMailbox.  This value can be set with the identity of a specific public folder mailbox or proxy to discretely control the connection initially made by Outlook. 

An Outlook client connects to public folders based on information it receives from an AutoDiscover query.  When Outlook requests information about the primary mailbox the Exchange server will send back the identity of the public folder mailbox (or a proxy if using remote public folders) to which it should connect and a second Autodiscover query is made for this identity.  The initial public folder connection is used for the browsing and expansion the public folder hierarchy.  When a user accesses the contents of a folder, Outlook will silently navigate to the content mailbox (modern) or database replica (legacy) holding the data on its own.  It is possible then for a single Outlook client to have many distinct public folder connections if each folder accessed has its contents on different mailboxes (modern) or databases (legacy).  It should be understood then in the context of Remote Public Folders, based on the above text, that it is Outlook that connects to public folders and not the Exchange server.  An Outlook user that connects to their mailbox off-network (from home or hotel for example), must also be able to connect to the server hosting public folders in the same way. 

Geographic User Connections to Public Folders

In an Office 365 deployment, there is no ability to geographically distribute public folder mailboxes or users’ connections to public folders.  Microsoft currently does not provide GeoTenant features for public folder mailboxes.  This may mean some differences in user experience if migrating from an on-premises environment.  For example, if prior to migration an Outlook client in Germany connects to a public folder database or mailbox that is hosted in Germany there is little or no network latency for that user.  After a migration to Office 365, and if the tenant was created in USA, the same Outlook user would then connect from Germany to USA for public folder hierarchy and content and browsing and viewing contents will appear slower and less responsive.

In contrast, an on-premises deployment can place specific public folder mailboxes on one or more databases in Germany so that German users have a local connection point for browsing the hierarchy.  Additional work can also be done to place the contents of public folders on mailboxes in Germany if desired.  However, modern public folders do not provide any ability for multiple copies of contents across geographic placements.  A USA user accessing the contents of a folder homed in Germany will have to traverse a long distance (high latency) connection to get the data and their experience will be affected.

User-specific Public Folder Connections

Microsoft added a feature to Exchange 2016 (CU13), Exchange 2019 (CU2), and Office 365 in October 2018 that allows administrators to discretely control whether mailbox users connect to public folders.  The feature is described in detail in this article named Announcing Support for Controlled Connections to Public Folders in Outlook.  The summary of this article is that an administrator can enable the feature by setting Organization Config (see: Set-OrganizationConfig) property PublicFolderShowClientControl to TRUE.  When the Organization Config property is TRUE, any mailbox with the property PublicFolderClientAccess set to FALSE will not receive Public Folder information in their AutoDiscover response and as a result will not have a connection to public folders.  Note that the mailbox property PublicFolderClientAccess defaults to FALSE and if the Organization Config property PublicFolderShowClientControl is set to TRUE without updating the mailboxes first, all users will lose access to public folders until the mailbox property is adjusted.  Priasoft recommends updating the mailbox property before setting the enabling this feature if there is intent for it to be used.

Maximum Supported Connections

According to Microsoft support documents, Exchange supports no more than 2000 concurrent connections to the same public folder mailbox.  While Exchange will return public folder connections at random from either the available hierarchy serving mailboxes or the RemotePublicFolderMailboxes list it will monitor connection counts it has provided to avoid exceeding the 2000 concurrent connections.  However, if using the mailbox property DefaultPublicFolderMailbox, administrators must track connection counts themselves.  Do not assign more than 2000 users to the same public folder mailbox with this value.

Public Folders DEFAULT Permissions

This topic is covered in greater detail in step #5 – Permissions Sync.  However, during the target environment preparation and before any new public folders are created in the hierarchy administrators should determine if the DEFAULT permission on the root folder ‘\’ should be changed.  When the first public folder mailbox is created in Exchange, the root public folder (the parent of all visible folders) is also created.  The root folder will be initially set with the DEFAULT delegate having Author rights.  The ‘Author’ permission role provides the following rights:  FolderVisible, Create items, Edit Own Items, Read all items, and Delete Own items.   The Author role may be more than expected or desired and may be different than the current setup or policy. 

If the DEFAULT delegate’s permission remains as is, every folder created – by the synchronization or other means – will inherit this permission.  The Priasoft PFSync will replace it with the source’s value, but until that time the new folders will have Author privileges.  Furthermore, after the migration is completed any new root-level folder created will inherit this value and such may be unexpected.  If there is a general policy or business behavior in which users have no rights and cannot browse the hierarchy unless given explicit rights to folders, the DEFAULT delegate should be changed to NONE before proceeding further.

Modern Public Folder Defaults

A new deployment of modern public folders – on-premises or Office 365 – has several default values that should be adjusted before staring the migration project.

The following properties are Organization Configuration Values and can be viewed and changed with the Get/Set-OrganizationConfig PowerShell commands.

Values at first setup/install:

These default values are far less than the support limits suggested by Microsoft’s own documentation.  Priasoft recommends changing the values as seen in the table following these comments before moving on to step #2.  Once the migration is completed, the values can be set to lower values if desired, however, note that if the new value is set lower than the size of any existing folder those folders will immediately become read-only and, if mail enabled, will not receive new mail and non-delivery responses will be generated.

Recommended Values:

Note that setting PublicFoldersEnabled to REMOTE without also setting RemotePublicFolderMailboxes will cause users to not connect to public folders and is considered an incorrect set of values.  Furthermore, if the target environment already has public folders in use by target environment users the REMOTE setting will cause them to be sent back to the source environment.  This can be complicated in a merger/acquisition scenario.  Please discuss with Priasoft support for strategies, expectations, and potential issues.

Throttling Policies

Microsoft Exchange, since Exchange 2007, has had features to control client access to data to prevent bad and rouge actors.  Throttling policies and the number of “levers of control” have increased with each version of Exchange.  Distilled down, throttling policies are a means to slow down or delay access across a timeline based on real-time metrics.  Throttling policies and the controls they provide are applied to the authentication token used to access data and are not associated with the specific resource (mailbox, address-book, public folder, etc.) being accessed.  For example, if User1 authenticates to Mailbox6 thru the FullAccess right, the throttling policy applies to User1.  Only Exchange-enabled users (e.g. mailboxes or mail-users) can be associated with a throttling policy, and only to one at a time.

All Exchange installations have a default throttling policy with several default values of which most are set low.  Additional throttling policies can be made (on-premises only) and users can be explicitly associated with a policy.  If an Exchange user does not have an explicit association the same user will be associated automatically to the default policy.  Additionally, there is also a static and immutable hard-coded policy that has severely low values and which is not exposed by any administrative tools.  This hidden hard-coded policy applies to anonymous user connections.  Anonymous user connections can occur from cross-forest connections.

The Priasoft synchronization solution defaults to connecting to public folders via a single authentication account.  If throttling policies are left as is it is very likely that the performance of the sync will suffer as a result.  Priasoft recommends that new throttling policies be created and all mapi-specific controls be removed (set to Unlimited).  Once created, the account(s) used by the sync should be associated with the new policy.  For reference review these commands: New-ThrottlingPolicy, Set-ThrottlingPolicy, and Set-ThrottlingPolicyAssociation.

Note that with Office 365 there is no ability to create new policies, adjust existing policy values, or set policy associations.  Furthermore, Microsoft has no ability to change many of the values related to MAPI.  The most commonly changed throttling policy values that can be changed are for user concurrency and specially for Exchange Web Services (EWS).  Priasoft overcomes this limitation by an ability to use multiple authentication accounts in order to distribute the policy budgets across those accounts so that no single account can exceed the budget.