Public Folder Migration Guide

⌘K
  2. Home
  4. Docs
  6. Public Folder Migration G...
  8. Migration Outline and Bes...
  10. Step 8 – Cutover Event Planning

Step 8 – Cutover Event Planning

Consistency Check and Delta Sync Speak with a Technical Expert Pre-Cutover Delta Sync
On Page Topics

This step in the project is where a discussion is made about the optimal time in the calendar to perform a cutover and to ensure that expectations are set properly.

The cutover event is conceptually simple and involves to key elements:

  • Changing mailbox user settings to point to the new public folder mailboxes.
  • Mail-enabling the new public folders, if necessary.

Note that the cutover event is really about end-user clients and not about the folders themselves.  At this point in the project 95-99% of all the data should have been synchronized to the target system.

The amount of time for a cutover event is mostly determined by the number of users that must be updated.  Updating user accounts is done by Set-Mailbox commands to point them to one of the target public folder mailboxes.  The Set-Mailbox command has a parameter named DefaultPublicFolderMailbox that allows for a static assignment to a user for a given public folder mailbox.  When Outlook makes its next AutoDiscover query for the mailbox the response will contain the newly assigned mailbox info and Outlook will connect to that mailbox for the user to browse the folder hierarchy.

Modern Outlook (outlook 2016 and later), while running, will re-query AutoDiscover once every hour.   Upon receiving the updated public folder value, it will drop the current hierarchy connection and create a new one.  In most cases user will not notice this change.   This also means the end user risk is very low since Outlook will either be connected to the old public folders or the new.  There is no normal case where Outlook would suddenly lose all connection to public folders.  Note however that although Outlook will re-query once an hour, it can take up to two hours or more before the Outlook updates the connection.  The reason is that update the mailbox settings with the DefaultPublicFolderMailbox value inherently has a delay before it reaches AutoDiscover.

If Outlook is not running when the cutover changes are made, Outlook may still take an hour after first launch to detect the change.  This is because on startup Outlook may use a cached version of the AutoDiscover response and as such would not know about the change until it normal cycle occurs to look for changes (once per hour).

Creating a new Outlook profile should cause the connection to immediately go to the new public folder system since there would not be any cached information to use.

Friction Points

Priasoft attempts to do as much as possible to preserve the end-user experience after cutover.  However, due to limitations of some elements of Outlook, not everything can be preserved.

Public Folder Favorites

One of the main points of friction following ANY public folder migration, regardless of tools used, are Public Folder Favorites.  Outlook has a feature whereby a user that is browsing the public folder hierarchy can right-click any given folder and “add to favorites”.  This creates a type of shortcut to the folder so that a user doesn’t have to walk down the tree to get to the contents or optionally the subtree of this folder.  Public Folder Favorites are stored in a special hidden folder in each user’s mailbox.  The data stored for each favorite is proprietary and mostly undocumented by Microsoft.  Priasoft knows from testing and reverse-engineering efforts that these favorites are storing the mapi EntryID of the specific folder and not the folder path.  The EntryID is a special binary value (very similar to the objectGuid property of an Active Directory object) that uniquely identifies a folder.  If a folder is moved from one parent folder to another, the EntryID does not change.  It is for this reason (as well as some others) that the folder path is not stored in the favorite.

The side effect of this is that there is no way for a user or administrator to determine the folder path for any given public folder favorite.  Right-clicking and showing the properties of a favorite will only show the path of the favorite itself, not the path of the folder to which it points.  If a user created the favorite months or years ago, the user may not be able to remember where the folder resides in the hierarchy.

When the cutover to the new public folders occurs for end users, existing favorites will no longer work and clicking on one will throw and error dialog to the end user.   There only resolution is to have the user remove the favorite and recreate the same, if desired.

The Priasoft PF Toolbox does have a feature that can scan and discover mailboxes that have favorites and can report on them, including calculating the related folder path for each favorite entry.  However, Priasoft has no ability to remove or update the favorites.  The reason is because there is no developer support for such actions and structure of the stored data has no documentation from Microsoft.  Priasoft’s ability to report on the data is solely due to reverse-engineering by some smart people on our development team, but no confidence could be made with regards to being able to properly update or remove the data with potentially causing some secondary issue at the same time.

Historically, Priasoft has found that only 10% or less of an organization uses public folder favorites.  However, this is an average across many customers and usage at your organization may be different.  The reporting mentioned above can help understand the permutation of this feature in your environment.  Note however that just because a mailbox has a public folder favorite does not mean the user actively uses it or even remembers that it exists.  There is no ‘last access time’ property for the favorite entries.

Public Folder Contacts Folder as Address Book

With similar caveats as for public folder favorites, a feature in Outlook exists whereby a user can make a public Contact folder appear in the users list of address books as a virtual address book.  This is a very rarely use feature and is buried behind several non-intuitive button clicks, but the feature exists, nonetheless.  This feature cannot be migrated or preserved and will be broken after cutover if in use.  Users will need to disable the feature before cutover if they want it removed from the list of address books.  After cutover there is no way to remove a bogus address book without creating a new outlook profile.  There is no reporting option available for this feature.

Public Folder Assistant Rules

Exchange public folders have, and always have had, the ability to create folder-specific rules that can provide automatic handling of items in folders for specific actions.  These are known as Folder Assistant Rules.  The rules are very similar to mailbox rules but are very narrowly scoped and are limited in criteria and action.  Common public folder rules are to delete or move data matching some criteria.  For mail-enabled public folders there are a few more options like responding with a template or redirecting to another recipient.

Priasoft is not able to migrate public folder rules.  The Priasoft Public Folder Analysis Toolbox (PFAnalyzer) product has the ability to identify folders with one or more rules, if such information is needed.

Historically, Priasoft finds that fewer than 5% of folders in the hierarchy have rules assigned, if any at all.

Mail-Enabled Public Folders (MEPFs)

Mail-Enabled Public Folders are a complex topic unto itself.  Priasoft has produced a article on this topic here:  Secret Challenges of Mail-Enabled Public Folders

In the context of the migration steps, public folders that are mail-enabled in the source environment should be mail-enabled in the target environment with the same values and settings.  The Priasoft PF Toolbox has an option to capture all the current MEPFs and to produce a PowerShell script to mail-enable the new folders.  The feature will capture the myriad of setting for which a MEPF can have such as, but not limited to:  email addresses, X500, group membership, send-as permissions, delivery restrictions, and more.

The ability to successfully execute this script depends upon the type of migration being performed.

Same-Forest Migration

For same-forest migrations the process requires that all currently mail-enabled public folders be mail-disabled and any remnants in Active Directory be removed.  The reason is that in a same-forest scenario there is only one address-book:  the Global Catalog.  As such, it is impossible to have more than one Active Directory object with the same email address(es).  If the current set of MEFPs are not mail-disabled, the new folders cannot receive the same email address (its already in use).

Inherently this means that if nothing else is done there will be a period of time between the mail-disabling and the mail-enabling where the email addresses simply do not exist in Active Directory and subsequently any inbound mail delivery targeting those objects will fail to delivery and a non-delivery report will be sent back to the sender.  For many environments this is not acceptable, and a strategy needs to be formed as to how to handle this.  Strategies are presented later in this section.

Cross-Forest Migration

In a cross-forest migration there exists a slightly different challenge.  While there is no issue mail-enabling the new folders in the target environment such does not ensure that mail will delivery to these newly enabled folders.  If the current mail routing does not pass through the target mail system, then inbound mail will still delivery to the source folders.  Priasoft highly recommends a review of mail routes and to determine if current routing paths will impact mail delivery to the new folders.  In conjunction with this, a review of all of the mail domains of all the email addresses found on public folders should be performed.  It is possible that external senders are sending to these folders using one of the non-primary email addresses.

If the current set of mail routes are such that inbound and internal mail will still deliver to the source public folders, forwarding may be necessary. 

Forwarding by Alternate Recipient

MEPFs, much like any other Exchange-enabled object, has the ability to forward mail elsewhere.  In order for this to work, mail contacts will have to be created in the source environment that have an email address that can be specifically routed to the target public folder.  This often requires the use of a custom mail namespace and a related send connector through which the mail will flow.  The mail contacts are then added as alternate recipients of the MEFPs.  This obviously breaks down if existing MEPFs already have a forwarder, perhaps to a shared mailbox or other user.  An Exchange object can only have one forwarder at a time.

Another quirk of this approach is that it requires the continued maintenance of the current mail gateway through which the mail routes.  If this sever is targeted for retirement as a part of this project, it will have to be delayed until a different mail routing option is used.  Furthermore, the existing MEPF objects in Active Directory will need to remain which may become confusing at best in the days and weeks following the cutover.

Forwarding by Conversion to Mail Contact

An alternative approach to the alternate recipient is to convert the MEFPs to mail contacts and let contacts do the forwarding of mail directly.  A side effect of this approach is that any user still operating in the source environment will not see these objects as public folders in the GAL anymore, but as Contacts.  Such may confuse users if expectations are not properly set ahead of time.  Not that this conversion is not trivial.  The conversion should follow the following pattern:

  1. Collect all the display properties
  2. Collect the legacyExchangeDN
  3. Collect the EmailAddresses (proxyAddresses)
  4. Collect the Alias (mailNickName)
  5. Collect all the distribution group memberships
  6. Mail disable the MEPF (or delete from Active Directory if the PowerShell command fails)
  7. Wait for Active Directory to replicate the deletion
  8. Create a new mail contact object and set all the collected values from above onto it.
    1. For the legacyExchangeDN, this should be added to the EmailAddresses as an X500: type.
  9. Add the new contact back to all the distribution groups

Note that in the above pattern, there is a risk of non-delivery for a short period of time between when the MEPF is disabled and the mail contact is fully restored.

Forwarding by Non-Authoritative Domain

The last option available consists of three elements:

  • All mail domains for the mail public folders must be set to non-authoritative
  • One or more send connectors created (where necessary) for the mail domains to forward mail to the target environment.
  • Mail disabling of all of the mail-enabled public folders

When the above three actions are performed, inbound mail targeting one of the mail-public-folders will be forwarded to the target environment for an attempted delivery.  This works because of the non-authoritative setting on the mail domains.  When a mail domain is set to non-authoritative, the hub transport in Exchange will still try to do a local search for an object with the destination email address but if not found the transport will search the available send connectors to determine if any can be used to reroute the message.  If one of the send connectors matches the mail domain of the destination address, the transport will use that connector to send mail to the configured target server or servers.

The side effect of this approach is that the mail-enabled public folders will no appear in the GAL of the source environment.  Internal senders from the source environment would need to know the email address of the public folder in order to send to it.  Additionally, any distribution groups that contained the MEPFs will no longer send mail to them.  For those cases a mail contact may be necessary.

Office 365 Migration

When migrating mail public folders to Office 365 all of the cross-forest concepts apply, but with some additional caveats and components.

Forwarding

If mail forwarding concepts will be used, the choice for the forwarding email address is pre-set and the requirement for additional send connectors is usually unnecessary.  Forwarding to the Office 365 folders should be done using the inherent @tenant‑name‑here.onmicrosoft.com email address.  In both hybrid and non-hybrid setups, this mail domain can always be used to send mail to objects.

Directory Based Edge Blocking (DBEB)

Office 365 has a feature called “Directory Based Edge Blocking” that moves the mail delivery acceptance check to AzureAD before reaching Exchange online.  This feature is enabled by default on new tenants and causes mail to only delivery if an object can be found in AzureAD containing the destination email address.  Unfortunately, this feature doesn’t work for MEPFs.  Mail enabled public folders never appear in AzureAD and there is currently no suggestion from Microsoft of including them.  Note that this only affects external senders.  Office 365 mailbox users in the same tenant are unaffected by this feature.  However, hybrid relays from on-premises are affected as that is still considered, technically, an external sender.  This means that forwarding from on-premises to Office 365 is also impacted by DBEB.  The only option is to disable DBEB if it will affect the use of mail enabled public folders.

Mail Public Folder Sync

Mail enabled public folders can be synchronized and made present in the GAL of Office 365 prior to the migration and cutover of public folders.  This may have already been done long before this project even started.  Microsoft provides two options to synchronize MEPFs to Office 365:

  • AzureAD Connect (dirsync)
  • Sync-ModernMailPublicFolders.ps1 (PowerShell script)

The AzureAD connect method causes the on-premises MEPFs to be synchronized by the same method that handles mailboxes, contacts, and distribution groups.  This method is rarely used and Priasoft does not recommend it use.  When MEPFs are synchronized using this process, the “fake” public folder objects created in Office 365 become read-only, just like any other object synchronized by this method.  As such, no changes to the cloud version of the object can be made nor can they be deleted directly.

The PowerShell script provided by Microsoft also synchronizes MEPFs to Office 365 but this process creates stand-alone objects in Office 365 that can be modified or removed afterwards.  The PowerShell script is an on-demand execution pattern unless a scheduled task is created to run the script on a schedule.

In either case and if used it creates a conflict for the mail-enabling of the actual public folders that have been synchronized to Office 365.  In order to mail-enable the Office 365 public folder and have it use the same email addresses and values from the on-premises folder, the “fake” public folder object must be removed.  There is no supported ability to convert the fake public folder into a real one.  The removal of the fake public folders also means that there is a risk of non-delivery during the period of time between the removal of the fake object and the mail-enabling of the real public folder.

The fake public folder objects, like any other mail enabled object in Exchange, have legacyExchangeDN values, can be members of distribution groups, and can have forwarding and delivery restrictions.  All of these features should be captured before removal and restored on the real folders once created with primary importance focused on the legacyExchangeDN value.

Exchange Online Limits

Office 365 has mail receive limits that don’t necessarily exist or match an on-premises setup.  Of most concern is the fact that Office 365 limits inbound mail to an object to 3600 items per hour.  If this value is exceeded, non-delivery reports will be sent to senders.  This limit is mentioned here because mail-enabled public folders are commonly used for high volume mail delivery.  The common use is for monitoring or logging messages, public response campaigns from marketing efforts, or other reasons.  A review of such behaviors should be made to determine if the Office 365 limits will have a critical impact on business use.  Further to this, the same sender sending to the same public folder is limited to 1,200 items per hour.

Use by Applications

A review of all applications that send mail to public folders should also be reviewed.  Such applications may need to be reconfigured to send mail directly to the target mail system, use forwarding objects, or be determined to break without resolution.  The last point may mean a delay of the cutover if critical applications cannot be updated to work with the migrated public folders.

Furthermore, applications and their integration with mail can be at different levels.  Many applications simply send mail using SMTP to an email address and use an internal mail gateway (usually a specific Exchange server).  Some applications may have their own mailbox from which mail is sent to public folders.  And some other applications may open and create data directly in public folders using Exchange Web Services (EWS), powershell, or even MAPI.

Applications that Send or Create Mail

For applications that send mail by SMTP, a review of how this is specifically performed is necessary.  Very often such applications use an internal and anonymous relay server for the sending of mail.  If the smtp server used is targeted for deprecation and removal, the application will obviously need to be updated to use a different mail server.

In cross-forest and cross-premises scenarios the previous concepts about mail routing are of importance again in this context.  If an application continues to use a mail gateway server from the source environment, mail delivery to the target folder will depend upon how the source environment is configured for forwarding.  If no forwarding is intended to be used because mail routing will be (or already is) using the target mail servers, current applications that use the source mail servers will fail to deliver mail and will need to be changed to send mail using one of the mail servers in the target environment.

Office 365 does not allow anonymous relay of mail.  It is also possible that an on-premises target environment is also configured without any anonymous relay gateways.  In these cases, applications have to be reconfigured to authenticate before sending mail and if the application provides no capability for such, the cutover may need to be delayed or the application identified as broken.

If applications exist that send mail at a high frequency, the Office 365 receive limits may affect the application’s behavior.  As mentioned earlier, Exchange Online limits inbound delivery to 3,600 items per hour per recipient and 1,200 items per hour from a single sender to the same receiver.

For applications that are more deeply integrated and create mail directly in folders, and if those applications behaviors are not changed, they will continue to create mail in the source public folders after cutover.  This would prevent the deprecation of the source public folder server(s) and would require continual use of the Priasoft PF Toolbox to sync those changes forward to the target environment.  Priasoft’s PF Toolbox is licensed in 1yr increments.

Strategies for Non-Delivery During Cutover

In the previous paragraphs it was mentioned several times about risks of non-delivery in cases where existing objects must be removed before mail-enabling the public folders.  Several strategies exist to handle this concern:

  • Ignore and allow the non-delivery to occur
  • Suspend all SMTP delivery and allow it to queue
  • Hold mail for specific email addresses and release after cutover
  • Change delivery endpoint entirely before cutover

Ignore and Allow Non-Delivery

While a first reaction to this may be shocking, often this can be the cleanest and simplest option.  If a review of mail delivery volumes to the mail-enabled public folders shows that either there is very little activity overall or that there is near zero activity over a specific time period (nights and weekends most likely), it may be best to do the cutover during a quiet period and to set expectations accordingly.  If one or a few messages do come in over the cutover period, a re-send of the message will succeed after cutover.

Suspend All SMTP

This option ensures that no mail is lost and that no mail is returned as a non-delivery.  However, this option affects ALL mail delivery, not just mail targeting public folders.  When mail delivery is suspended, it will queue at the previous hop in the mail route.  This is an inherent ability of SMTP and the queue will hold mail for up to 4 days before being returned.

For cases where delivery of mail to public folders is important, this tends to be the best and safest option.  Expectations would need to be set to users that they may see a delay in mail delivery.   The duration of the delay will should only be a few minutes our hours to possibly 24 hours or slightly more and is influenced by the quantity of mail-enabled public folders that have to be processed.  A 24-hour or longer duration would be for cases where there are 10s of 1000s of mail-enabled public folders to process.

Once all public folders have been processed, and mail forwarding setup, the queued mail will be delivered to the target public folders when the SMTP suspension is removed.

Hold Mail for Specific Addresses

This option can be used to hold mail only for the mail-public-folders that are important to not have delivery failures (or all).  This option is not available with on-premises Exchange directly but can be used in Office 365 or possibly by a mail gateway outside of Exchange.

Office 365 has a feature called “Hosted Quarantine”, which is a type of mail transport rule.  Using this rule one can set one or more SMTP addresses for which the rule applies and inbound mail to those addresses will be placed in “quarantine”, which is a type of holding queue for mail.  Once the public folder cutover actions complete, the rule can be disabled and removed, and the quarantined mail can be “released” and will then delivery to the target public folders.  A quirk of this option is that a single transport rule has a limit as to the number of email addresses it can target.  The limit is a total byte size limit of all the addresses and so the quantity of address values will vary depending upon the length of each address.  Experience has shown that a few hundred address per rule is possible and multiple rules can be used if needed.

For non-Office365 scenarios, the same may be possible if an upstream mail gateway has similar capability.  However, a quirk of this scenario is that it will only work for external senders.  Internal senders would not route through the gate way and would be solely handled by the Exchange server itself.

Change Delivery Endpoints

This option is simply one that changes the delivery of mail from the mail-public-folder to some other object like a shared mailbox.  Essentially this is a conversion option whereby the mail-public-folder is disabled for mail delivery and the email addresses, legacyExchangeDN, and group memberships are captured and applied to a user or shared mailbox, distribution group, or contact.

As in other cases there will exist a small risk of non-delivery in the time between the mail-disabling of the public folder and the email address(es) appearing on the converted object.   However, on a single object such as this the duration of this should only be a few minutes.

How can we help?