When connection to Exchange Online PowerShell using the command Connect-ExchangeOnline nothing special happens. But when executing a PowerShell command like Get-Mailbox you get the following warning:
PS C:\WINDOWS\system32> $mailboxes = Get-mailbox -ResultSize unlimited
Attention!
You are currently using an older version of the Exchange Online PowerShell module which uses RPS. RPS deprecation has been announced and you will need to move to the latest V3 module by June 2023. Read more here: https://aka.ms/RPSDeprecation
Please install our new REST-based PS V3 module downloadable from https://www.powershellgallery.com/packages/ExchangeOnlineManagement/, which is more secure and reliable.
Please note that you will no longer be able to use -UseRPSSession after June 2023.
Microsoft has introduced a new Exchange Online PowerShell module (v3) and the previous modules will be deprecated in the (near) future.
To update the PowerShell module, the old module needs to be uninstalled first before you can install the latest version. To uninstall the old v2 module, execute the following command:
Uninstall-Module ExchangeOnlineManagement
And to install the new v3 module, execute the following command:
Many customers are running in an Exchange hybrid environment where they have mailboxes in Exchange Online and in Exchange on-premises and a lot of my customers have Exchange 2016 running on-premises. Not a lot of customers still have Public Folders in Exchange on-premises, but they are still there. This blog explains steps to migrate Modern Public Folders from Exchange 2016 to Exchange Online, but this blog is also valid for modern Public Folders in Exchange 2013 and Exchange 2019. If you are still running Exchange 2010 and you want to move your (legacy) Public Folders to Exchange Online, follow the steps in this Microsoft article: Use batch migration to migrate legacy public folders to Microsoft 365 or Office 365.
Note. This is a long read. It has also been a long project, preparations took a couple of weeks, the synchronization a couple of days, roll-back after the first attempt to finalize the migration and start over again with fixing the unexpected issues. When migration Public Folder from Exchange 2016 to Exchange Online, take your time and do it right!
When to migrate your Public Folders to Exchange Online
Public Folder access cross-premises is one-way only. Mailboxes in Exchange Online can access Public Folders in Exchange on-premises, but not the other way around. So, mailboxes in Exchange on-premises cannot access Public Folders in Exchange Online. You should only migrate Public Folder to Exchange Online, after you have migrated all user mailboxes to Exchange Online.
Note. I deliberately say “user mailboxes” in this context, you can still have mailboxes in Exchange on-premises for applications, service accounts, devices etc. that do not need to access Public Folders.
Requirements
The following requirements on-premises need to be met before the migration of Public Folders to Exchange Online can be started:
Exchange 2016 CU4 or higher (which is a no brainer in my opinion)
The Exchange administrator needs to be a member of the Organization Management role group (in Exchange Online and in Exchange 2016)
Public Folders need to be less than 25GB in size
User mailbox migration need to be finished before Public Folder migration starts
Migration needs to be executed using Exchange PowerShell. The Public Folder Migration option is not available in the Exchange Admin Center
All Public Folder data must be migrated in one single migration batch
Verify if the DefaultPublicFolderAgeLimit is configured on the organization level or if you have any AgeLimit configured for the individual Public Folders, so that automatic deletions of the content is prevented
e domains, the Exchange system objects (like mail-enabled Public Folder objects) can reside in multiple locations since these locations have changed over the years (with different versions of Exchange). Sometimes these object can be found in the root domain, but also in a child domain. If you are using an Active Directory environment with multiple domains, make sure you extend the scope of Powershell using the following command:
The SourceSideValidations.ps1 script does an inventory of all Public Folders in the Exchange organization and reports any issues that are found and can cause problems during the Public Folders migration.
The results of this script are written in the SourceSideValidations.csv in the PFScripts directory and contains something like this:
ResultType
Severity
Count
Action
TotalItemSize
Error
2
Items should be deleted from these folders until the folder size is less than 25 GB.
EmptyFolder
Information
138
Folders contain no items and have only empty subfolders. These will not cause a migration issue, but they may be pruned if desired.
SpecialCharacters
Error
12
Folders have characters @, /, or \ in the folder name. These folders should be renamed prior to migrating. The following command can be used:
Mail public folders are orphaned. They exist in Active Directory but are not linked to any public folder. Therefore, they should be deleted. After confirming the accuracy of the results, you can delete them manually, or use a command like this to delete them all: Import-Csv .\ValidationResults.csv | ? ResultType -eq OrphanedMPF | % { $folder = <see below> $parent = ([ADSI]”$($folder.Parent)”) $parent.Children.Remove($folder) }
OrphanedMPFDuplicate
Error
3
Mail public folders point to public folders that point to a different directory object. These should be deleted. Their email addresses may be merged onto the linked object. After confirming the accuracy of the results, you can delete them manually, or use a command like this: Import-Csv .\ValidationResults.csv | ? ResultType -eq OrphanedMPFDuplicate | % { $folder = <see below> $parent = ([ADSI]”$($folder.Parent)”) $parent.Children.Remove($folder) }
OrphanedMPFDisconnected
Error
1
Mail public folders point to public folders that are mail-disabled. These require manual intervention. Either the directory object should be deleted, or the folder should be mail-enabled, or both. Open the ValidationResults.csv and filter for ResultType of OrphanedMPFDisconnected to identify these folders. The FolderIdentity provides the DN of the mail object. The FolderEntryId provides the EntryId of the folder.
Badpermission
Error
89
Invalid permissions were found. These can be removed using the RemoveInvalidPermissions switch as follows: .\SourceSideValidations.ps1 -RemoveInvalidPermissions
Note. In this table in row 4 and row 5 there’s the $folder variable. I was able to add the PowerShell command in there, so here’s the command. Please substitute as needed:
$Folder = ([ADSI]("LDAP://$($_.FolderIdentity)"))
Besides reporting the issues, the last column also reports the solutions about how to solve the issues. These are (also) discussed in the next section.
2. Prepare for the migration
The SourceSideValidations.ps1 script is a good starting point as it returns a number of potential issues for the migration and these need to be fixed before you can start the migration:
The TotalItemSize is easy to fix. Remember that the size is per folder, so if you have a large folder containing for example 40GB of data, you can create 3 subfolders and move 10GB of data in each subfolder. Problem solved š
The EmptyFolder is informational. You can migrate these to Exchange Online, or decide to remove them before the migration.
Public Folder names that contain a backslash or a forward slash are not supported in Exchange Online. These are also reported by the SourceSideValidations.ps1 script. To check for Public Folders containing these characters, you can use the following commands in Exchange PowerShell on-premises:
Check for orphaned folders, duplicate orphaned folders and disconnected orphaned folders. You can try to mail-disabled the corresponding Public Folder and re-enable the Public Folder again. I have also seen situations where the Exchange object in Active Directory (in the Microsoft Exchange System Objects container) was deleted using ADSI Edit.
Confirm SMTP Email addresses and Accepted Domains in Exchange on-premises and Exchange Online match. Most likely this is the case since all (user) mailboxes are already migrated, but it can happen that an email address is set on a Public Folder in Exchange 2016 with a domain thatās unknown in Exchange Online (contoso.local for example).
Also, make sure your public folders are stamped with a Microsoft online email address, like folder@contoso.mail.onmicrosoft.com. This makes life much easier after the migration, when you still have local application trying to send email to public folders.
Create an Accepted Domain with a well-known name to prevent messages getting lost in the DNS transition period. To do this, execute the following command in Exchange PowerShell on-premises:
Create a snapshot of the existing Public Folder environment in Exchange 2016. This can be useful when checking if the Public Folder migration was successful. The following four commands will export the Public Folders, the Public Folder Statistics, the Public Folder permissions and the mail-enabled Public Folders. Be aware that this can take a considerable amount of time, depending of the number of Public Folders in your organization.
In Azure AD Connect thereās the option to synchronize Exchange Mail Public Folders to Azure AD, as shown in the following screenshot:
This is used for Directory Based Edge Blocking (DBEB) only so that external mail for Public Folders is not blocked by DBEB. DBEB is automatically available when recipients are in Exchange Online, so thereās no need to synchronize this using Azure AD Connect. Uncheck the Exchange Mail Public Folders in the Optional Features in Azure AD Connect.
Note. When the issues are solved and all prerequisites are met, run the SourceSideValidations.ps1 script again to see if no more issues are returned.
3. Generate .CSV Files
If you have done all the prerequisite step, itās time to generate the CSV files in preparation of the actual Public Folder migration to Exchange Online.
The first CSV file is the Name-to-Folder size mapping file. This file contains three columns: FolderSize, DeletedItemSize and Foldername. To create this file, execute the Export-ModernPublicFolderStatistics.ps1 script with a filename option, like this:
The second CSV is created using the ModernPublicFolderToMailboxMapGenerator.ps1 script. This script creates a mapping between the Public Folders from the previous step to mailboxes in Exchange Online. For input, this script takes the CSV file from the previous step, together with the maximum Public Folder mailbox size and the maximum mailbox recoverable items quota.
The maximum mailbox size by default is 100GB, but it recommended to use 50GB here to anticipate for future growth of the Public Folders in this mailbox. The recommended size for recoverable items quota is 15GB.
The command to execute this script is something like this:
When you look at the output file you will see only two columns: TargetMailbox and FolderPath. The TargetMailbox shows the Public Folder mailboxes that will be created. These Public Folder mailboxes have generic names, like Mailbox1, Mailbox2, Mailbox3 etc. You can change the Public Folder mailbox names in the CSV file into something thatās more suitable for your environment, for example PFMailbox1, PFMailbox2, PFmailbox3 etc.
4. Create Public Folder mailboxes in Exchange Online
When all information has been gathered the Public Folder mailboxes can be created. One Public Folder mailbox will be used for the Public Folder hierarchy (this will be primary mailbox, and the first mailbox in the CSV file that was created earlier) and the others are used for storing the Public Folders contents.
To create the Public Folder mailboxes, use the following commands in Exchange Online (!) PowerShell:
It is possible that some warning messages appear because of AD replication within Exchange Online as can be seen in the following screenshot. Just wait some time and these Public Folder mailboxes will become automatically.
5. Start Migration Request
Before starting the migration request, start the synchronization of mail-enabled public folders to Exchange Online. In my current project I donāt have to do this since this script was already running as part of the hybrid configuration (mailboxes in Exchange Online, Public Folders in Exchange 2016).
Note. Be aware that you use the latest version of this script. Older version (prior to June 2022) do not support Modern Authentication and will fail with an Access Denied error. I have blogged about this a couple of months ago: Sync-ModernMailPublicFOlders.ps1 fails with access denied.
It is possible that error messages are shown on the console, and if you have a lot of Public Folders these can also be quite a lot (been there, done that unfortunately), but you can import the sync_summary.csv file into Microsoft Excel for detailed analysis.
To create the migration request, we need the source credential of the PF Administrator, the endpoint where the MRS is running, the GUID of the hierarchy mailbox in Exchange 2016 and the Public Folder mapping file (PFMapping.csv) that was created in the previous step.
Execute the following command in Exchange 2016 PowerShell. Copy the value of $HierarchyGUID to (for example) Notepad since it will be used in the last command where the actual migration batch is created.
Note. Please take some time between creating the Public Folder mailboxes (especially the primary hierarchy mailbox), the New-MigrationEndpoint command will fail if thereās not enough time for internal Exchange Online replication, causing error messages like āmailbox <GUID> cannot be foundā.
When created you can start the migration request using the following command in Exchange Online Powershell:
When the migration batch is started, it will create a number of Public Folder Mailbox Migration Requests, depending on the number of Public Folder Mailboxes. In this example, there are 18 Public Folder mailboxes and 18 individual migration requests will be created as part of the migration batch. It took up to 4 hours before all migration requests were created. Be aware of this because at first you will be thinking that something is wrong š
Use the following commands in Exchange Online PowerShell to monitor the migration batch and the individual migration requests:
What I personally do for some more details is adding some more options and using the format-table feature, like this:
[PS] C:\PFScripts\> Get-PublicFolderMailboxMigrationRequest | Get-PublicFolderMailboxMigrationRequestStatistics | Select TargetMailbox,Status,StatusDetail,ItemsTransferred,BytesTransferred,BytesTransferredPerMinute,PercentComplete | ft -a
If for some reason you have failed migration requests in your migration batch, you can always run the Start-MigrationBatch -Identity PublicFolderMigration command to resume the batch.
Another interesting issue I had was that the PFMailbox1 that holds the hierarchy, failed synchronization with StatusDetail āFailedOtherā. When requesting the PublicFolderMailboxMigrationStatistics for this PFMailbox, the following error is returned:
olderMappingFlags: InheritedInclude" could not be mail-enabled. The error is as follows: "No mail public folder was found in Active Directory with OnPremisesObjectId='dd887445-0b0a-447f-a6fc-889cc49ab16c' or LegacyExchangeDN='/CN=Mail Public Folder/CN=Version_1_0/CN=e71f13d1-0178-42a7-8c47-24206de84a77/CN=000000006F0ABC0AC0DF544387022DEA38DAE5840100F33760E70CFA4C489E930054C1EC880900038611485B0000'". This may indicate that mail public folderobjects in Exchange Online are out of sync with your Exchange deployment. You may need to rerun the script Sync-MailPublicFolders.ps1 on your source Exchange server to update mail-enabled public folder objects in Exchange Online Active Directory.
Synchronization takes a couple of days (I started on Tuesday and plan to finalize the next weekend) and during that time new mail-enabled Public Folders are created and synchronized.
To bring this back in sync, run the Sync-ModernMailPublicFolders.ps1 script again, wait some time (for replication in Exchange Online) and start the migration batch again.
Remember that up to this point, users can continue to work just like they can when their mailbox is migrated to Exchange Online. Only when the migration request is finalized the Public Folders are not available.
6. Lockdown Public Folders in Exchange 2016
Finalizing the Public Folder migration is not different than when migrating Mailboxes from Exchange 2016 to Exchange Online. When the finalization takes places, users are logged off of the Public Folders, the last content is migrated to Exchange Online and the Public Folder mailboxes in Exchange Online become active. However, they are not automatically available to users, some additional steps (including testing) are needed.
Important to note is that a Public Folder migration finalization can take a lot of time, depending on the number of folders, the number of items (equals data) and if there are corrupt ACLs in the source Public Folders. Microsoft recommends to plan at least 48 hours of downtime during the Public Folder migration finalization.
To check if the Public Folder migration batch is successfully synced (and thus ready to finalize) use the following commands in Exchange Online PowerShell:
Preferably, the LastSyncedDate on the migration batch and the LastSuccessfulSyncTimestamp on the individual jobs) should be within the last 7 days as can be seen in the following screenshot. If itās not, check the Public Folder migration requests to see why it is not in sync.
If all is ok, you can lock down the Public Folders in Exchange 2016 by executing the following command in Exchange PowerShell:
After (Active Directory) replication you can check if Public Folders do not accept new connections anymore by typing the following command in Exchange PowerShell:
[PS] C:\PFScripts> Get-PublicFolder \
It should generate an error message saying āCould not find the public folder mailboxā as shown in the following screenshot:
7. Finalize Public Folder migration
Before finalizing the Public Folder migration you should run the SyncModernPublicFolders.sp1 script again to make sure that newly created Mail-Enabled Public Folder (or better, their email addresses) are synchronized with Exchange Online.
Migrationbatch status will change from Synced to Completing. This can take a tremendous amount of time; Microsoft recommendation is to take 48 hours into account for this. In my scenario, there are 18 Public Folder mailboxes that are sync. The on-premises Public Folders were closed around 10PM on Friday night, but after twelve hours all Public Folder Mailbox Requests still had a status of āsyncedā. But when requesting the details of the migration batch (Get-MigrationBatch | fl) the TriggeredAction property of the migration batch was set to SyncAndComplete. Microsoft also says that it can take up to 24 hours before the status of the migration batch and the corresponding migration requests change from āsyncedā to āCompletingā. In the meantime, you can only wait, and check back every few hours. Eventually the migrationbatch status will change to Completed.
When the migration batch is completed you can test the Public Folders in Exchange. To do this, configure a user account with the default Public Folder mailbox in Exchange Online, using the following command in Exchange Online PowerShell:
The default Public Folder mailbox is the first PF mailbox (holding the hierarchy) that was created in a previous step using the ModernPublicFolderToMailboxMapGenerator.ps1 script.
Make sure you can see the PF hierarchy, check the permissions, create some Public Folders (and delete them) and post some content into Public Folders (both direct as via email). In our first attempt, permissions failed and we had to roll-back the migration. It took over 6 weeks before we could do a second attempt (ok, I have to admit, it was holiday time, but still….).
When tested successfully, change the Public Folders for all users. This is an organizational setting and can be changed using the following command in Exchange Online PowerShell:
[PS] C:\PFScripts> Set-OrganizationConfig -RemotePublicFolderMailboxes $Null -PublicFoldersEnabled Local
It is possible that SMTP message are stuck in SMTP Queues on the Exchange 2016 servers during the migration. To redirect these stuck messages run the following command on your Exchange 2016 server:
To stamp Mail-Enabled Public Folder objects in Active Directory with an external email address in Exchange Online (i.e. @contoso.mail.onmicrosoft.com) execute the following PowerShell script in Exchange 2016:
And the ultimate last step, set the Public Folders in Exchange 2016 to āremoteā. This is an organizational settings and can be configured by executing the following command in Exchange 2016:
After some time, if you are 100% sure you are not going to roll-back your Public Folder migration, the Public Folder Mailboxes in Exchange 2016 can be removed. Remember, this step is irreversible!
Roll-back Public Folder migration
If for some reason you must roll-back the migration you must execute the PowerShell commands in a reverse order. Be aware that if you roll back the migration after you finalized the migration, you will lose all mail delivered to the Public Folders in Exchange Online (unless you manually copy all new items to a location in a mailbox, which is practically impossible of course).
The first step is to unlock the Public Folder migration in Exchange 2016 by using the following command:
You should now be able to continue to work with the Public Folders in Exchange 2016.
Send-As and Send-on-Behalf permissions
A common pitfall is that Send-As and Send-on-Behalf permissions are not migrated to Exchange Online. If you are using these permissions you have to identify the Public Folders that have these permissions applied using the following commands:
Most likely you will have tons of Public Folders with these permissions, to you must first export to a CSV file, following with an import of the CSV file and assigning permissions in Exchange Online.
Allow anonymous users to send email to a mail-enabled Public Folder
I did not run into this after the migration to Exchange Online, but it might be possible that you lose the anonymous user permissions to send mail to a public folder after the migration. To make sure anonymous users can send email to a Public Folder, use the following command in Exchange Online PowerShell:
In this blog I tried to write down my experiences with a recent Public Folder migration from Exchange 2016 to Exchange Online. Depending on your Public Folder infrastructure this can take a considerable amount of time. And even if you have everything right, there still is the possibility that something goes wrong and you have to start all over again.
Although after the migration the Public Folder infrastructure is Microsoft’s problem and you only have the service available, I still recommend not migrate your Public Folders to Exchange Online and look for a different solution like Microsoft 365 Groups, Shared Mailboxes or Microsoft Teams. That’s the better solution, and at least it’s more future proof than Public Folders.
Such a simple problem, took me over an hour to find the simple solution…
When trying to use Exchange Online PowerShell I wanted to import the correct module using the Import-Module ExchangeOnlineManagement command. It failed with the following error:
Import-Module : The specified module 'ExchangeOnlineManagement' was not loaded because no valid module file was found in any module directory.
In the end it turned out to be some sort of typo…. Install-Module -Name ExchangeOnlineManagement works as expected. Sigh…. š
Currently I am working with a customer on this specific scenario, and to my surprise I ran into this Teams/Exchange connectivity test on the Microsoft Remote Connectivity Analyzer (https://aka.ms/exRCA). Open the Remote Connectivity Analyzer, select Microsoft Teams and click the Teams Calendar Tab button. Login with the account you want to test (in this example I have an on-premises mailbox on Exchange 2019, but works for Exchange 2016 as well) and click Perform Test.
Within seconds you will see if connectivity from Microsoft Teams to your Exchange server is working properly. Very nice!
After decommissioning the Resource Forest I still have an Exchange 2016 environment on-premises, but all my mailboxes are in Office 365. Users are provisioned in Active Directory, Remote Mailboxes are provisioned in Exchange 2016 and everything is synchronized to Office 365 using Azure AD Connect.
Do I still need an Exchange Hybrid Configuration? Unless there are plans to move resources back to Exchange on-premises thereās no need for a Hybrid Configuration. To stay in a supported configuration, an Exchange server on-premises is still needed for management purposes, but only Azure AD Connect is needed and not a full hybrid configuration.
Note. If you want to use the on-premises Exchange server for SMTP relay purposes you donāt need the Hybrid configuration either. Just make sure you have a SMTP Send Connector that points to Exchange Online Protection and youāre good.
Removing the Hybrid configuration consists of the following steps:
Disable Autodiscover SCP in Exchange
Remove the Hybrid Configuration from Active Directory
Remove Connectors in Exchange Online
Remove the Organization Sharing from Exchange Online
Disable OAuth
Disable Autodiscover SCP in Exchange
When all Exchange resources are in Exchange Online you no longer need the on-premises Service Connection Points (SCP) for Autodiscover. But make sure you have the correct CNAME records for Autodiscover that point to Autodiscover.outlook.com.
To disable the SCP records in Active Directory, execute the following command in Exchange Management Shell:
Remove the Hybrid Configuration from Active Directory
Removing the Hybrid Configuration from Active Directory is just one PowerShell command in Exchange Management Shell:
Remove-HybridConfiguration -Confirm:$false
Thereās one pitfall here, this will also remove the outbound to Office 365 Send Connector from Exchange. If you want to keep SMTP relay from on-premises to your mailboxes in Exchange Online you have to manually recreate this connector (use yourdomain-com.mail.protection.outlook.com as a smarthost for this)
Remove Connectors in Exchange Online
In the Exchange Online Admin Center, remove the outbound SMTP connectors that point from Exchange Online to your on-premises Exchange organization. If you want to keep SMTP routing, keep the inbound SMTP connector, otherwise you can remove this as well.
Remove the Organization Sharing from Exchange Online To remove the Hybrid Organization Sharing from Exchange Online navigate to Organization | Sharing in the Exchange Admin Center and remove the organization sharing.
Disable OAuth on-premises
When used before you can disable the OAuth configuration as well from Exchange on-premises and Exchange Online.
In Exchange on-premises Management Shell, execute the following command:
These are the steps needed to remove the Hybrid Configuration from your Exchange environment.
Note. Microsoft recommends to leave the Exchange Hybrid option in Azure AD Connect.
Summary
In this blogpost I explained how to remove the Hybrid Configuration from your Exchange environment after you have moved all resources to Exchange Online.
The on-premises Exchange server is still needed for management purposes. After removing the Hybrid Configuration you can still manage your recipient Exchange Online using the on-premises Exchange server, all changes are replicated through Azure Active Directory.
Is that last Exchange server on-premises still needed? Yes, you need it for managing your recipients in Exchange Online. When you have Azure AD Connect running in your environment, the objects are managed in on-premises Active Directory. The source of authority is Active Directory. As long as Microsoft hasnāt fixed the source of authority problem, an Exchange server on-premises is still needed.
You must be logged in to post a comment.