Category Archives: Exchange

Migrating Exchange 2016 Public Folders to Office 365

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.


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:

[PS] C:\> Set-ADServerSetting -ViewEntireForest $True

Migration Steps

Migration of Public Folders from Exchange 2016 to Exchange Online consists of the following steps:

  1. Download the migration scripts
  2. Prepare for the migration
  3. Generate the CSV files
  4. Create Public Folder mailboxes in Exchange Online
  5. Start Migration Request
  6. Lockdown Public Folders in Exchange 2016
  7. Finalize Public Folder migration
  8. Test and unlock Public Folders in Exchange Online
  9. Finalize the migration in Exchange 2016

These steps will be discussed in the following sections.

1. Download the migration scripts

Download the premigration or source side validation script from the Microsoft website (SourceSideValidations.ps1) and the Public Folder migration scripts ( Store the scripts on the Exchange server in the C:\PFScripts directory.

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:

TotalItemSizeError2Items should be deleted from these folders until the folder size is less than 25 GB.
EmptyFolderInformation138Folders contain no items and have only empty subfolders. These will not cause a migration issue, but they may be pruned if desired.
SpecialCharactersError12Folders have characters @, /, or \ in the folder name. These folders should be renamed prior to migrating. The following command can be used:

Import-Csv .\ValidationResults.csv |
? ResultType -eq SpecialCharacters |
% {
$newName = ($_.ResultData -replace “@|/|\”, ” “).Trim()
Set-PublicFolder $_.FolderEntryId -Name $newName
OrphanedMPFError37Mail 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)”)
OrphanedMPFDuplicateError3Mail 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)”)
OrphanedMPFDisconnectedError1Mail 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.
BadpermissionError89Invalid 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:
[PS] C:\> Get-PublicFolder -Recurse -ResultSize Unlimited | Where {$_.Name -like "*\*" -or $_.Name -like "*/*"} | Format-List Name, Identity, EntryId

To remove these illegal characters, you can use the following commands in Exchange PowerShell on-premises:

Import-Csv .\ValidationResults.csv | ? ResultType -eq SpecialCharacters |
% {
  $newName = ($_.ResultData -replace "@|/|\\", " ").Trim()
  Set-PublicFolder $_.FolderEntryId -Name $newName
  • 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 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:
[PS] C:\> New-AcceptedDomain -Name PublicFolderDestination_78c0b207_5ad2_4fee_8cb9_f373175b3f99 -DomainName "" -DomainType InternalRelay
  • 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.
[PS] C:\> Get-PublicFolder -Recurse -ResultSize Unlimited | Export-CliXML OnPrem_PFStructure.xml
[PS] C:\> Get-PublicFolderStatistics -ResultSize Unlimited | Export-CliXML OnPrem_PFStatistics.xml
[PS] C:\> Get-PublicFolder -Recurse -ResultSize Unlimited | Get-PublicFolderClientPermission | Select-Object Identity,User,AccessRights -ExpandProperty AccessRights | Export-CliXML OnPrem_PFPerms.xml
[PS] C:\> Set-ADServerSettings -ViewEntireForest $True
[PS] C:\> Get-MailPublicFolder -ResultSize Unlimited | Export-CliXML OnPrem_MEPF.xml

  • 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:

[PS] C:\PFScripts\> .\Export-ModernPublicFolderStatistics.ps1 On_Prem_Stats.csv

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:

[PS] C:\> PFScripts\ .\ModernPublicFolderToMailboxMapGenerator.ps1 -MailboxSize 50GB -MailboxRecoverableItemSize 15GB -ImportFile On_Prem_Stats.csv -ExportFile PFMapping.csv

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:

$PFMappings = Import-Csv C:\PFScripts\PFMapping.csv
$PrimaryMailboxName = ($PFMappings | Where-Object FolderPath -eq "\").TargetMailbox
New-Mailbox -HoldForMigration:$True -PublicFolder -IsExcludedFromServingHierarchy:$False $PrimaryMailboxName
($PFMappings | Where-Object TargetMailbox -ne $PrimaryMailboxName).TargetMailbox | Sort-Object -Unique | ForEach-Object { New-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$False $_}

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).

But to start this, run the following command:

[PS] C:\PFScripts> .\Sync-ModernMailPublicFolders.ps1 -CsvSummaryFile:sync_summary.csv

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.

[PS] C:\PFScripts> $HierarchyGUID = (Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid.GUID

Execute the following command in Exchange Online PowerShell:

[PS] C:\PFScripts> $Source_Credential = Get-Credential Contoso\Administrator
[PS] C:\PFScripts> $Source_RemoteServer = ""
[PS] C:\PFScripts> $Mapping = [System.IO.File]::ReadAllBytes('C:\PFScripts\PFMapping.csv')
[PS] C:\PFScripts> $PfEndpoint = New-MigrationEndpoint -PublicFolder -Name PublicFolderEndpoint -RemoteServer $Source_RemoteServer -Credentials $Source_Credential
[PS] C:\PFScripts> New-MigrationBatch -Name PublicFolderMigration -CSVData $Mapping -SourceEndpoint $PfEndpoint.Identity -SourcePfPrimaryMailboxGuid <HierarchyGUID> -NotificationEmails

As shown in the following screenshot:

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:

[PS] C:\PFScripts> Start-MigrationBatch PublicFolderMigration

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:

[PS] C:\PFScripts> Get-PublicFolderMailboxMigrationRequest
[PS] C:\PFScripts> Get-PublicFolderMailboxMigrationRequestStatistics
[PS] C:\PFScripts> Get-MigrationBatch -Identity PublicFolderMigration

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:

[PS] C:\PFScripts> Get-MigrationBatch -Identity PublicFolderMigration | ft *last*sync*
[PS] C:\PFScripts> Get-PublicFolderMailboxMigrationRequest | Get-PublicFolderMailboxMigrationRequestStatistics |ft targetmailbox,*last*sync*

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:

[PS] C:\PFScripts> Set-OrganizationConfig -PublicFolderMailboxesLockedForNewConnections $true

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.

[PS] C:\PFScripts> .\Sync-ModernPublicFolders.ps1 -CsvSummaryFile:Sync_Summary.csv

And to complete the migration batch:

[PS] C:\PFScripts> Complete-MigrationBatch PublicFolderMigration

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:

[PS] C:\PFScripts> Set-Mailbox -Identity <user> -DefaultPublicFolderMailbox PFMailbox1

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:

[PS] C:\PFScripts> $Server=Get-TransportService;ForEach ($t in $server) {Get-Message -Server $t -ResultSize Unlimited| ?{$_.Recipients -like "*PF.InTransit*"} | ForEach-Object {Suspend-Message $_.Identity -Confirm:$False; $Temp="C:\ExportFolder\"+$_.InternetMessageID+".eml"; $Temp=$Temp.Replace("<","_"); $Temp=$Temp.Replace(">","_"); Export-Message $_.Identity | AssembleMessage -Path $Temp;Resume-message $_.Identity -Confirm:$false}}

To stamp Mail-Enabled Public Folder objects in Active Directory with an external email address in Exchange Online (i.e. execute the following PowerShell script in Exchange 2016:

[PS] C:\PFScripts> .\SetMailPublicFolderExternalAddress.ps1 -ExecutionSummaryFile:mepf_summary.csv

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:

[PS] C:\PFScripts> Set-OrganizationConfig -PublicFolderMailboxesMigrationComplete:$true -PublicFoldersEnabled Remote

8. Remove Public Folder Mailboxes

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:

[PS] C:\> Set-OrganizationConfig -PublicFoldersLockedForMigration:$False

Delete all Public Folder mailboxes in Exchange Online using the following Powershell commands:

PS] C:\> $hierarchyMailboxGuid = $(Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid
[PS] C:\> Get-Mailbox -PublicFolder:$true | Where-Object {$_.ExchangeGuid -ne $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -Confirm:$false -Force
[PS] C:\> Get-Mailbox -PublicFolder:$true | Where-Object {$_.ExchangeGuid -eq $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -Confirm:$false -Force

If you run into issues with this, check one of my previous blogs Multiple Mailbox users match identity “Mailbox1” (which I ran into after a roll-back and a 2nd migration attempt).

The last step is to undo the migration completion in the organization config of Exchange 2016 using the following command:

[PS] C:\> Set-OrganizationConfig -PublicFolderMigrationComplete:$False

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:

[PS] C:\> Get-MailPublicFolder | Get-ADPermission | ?{$_.ExtendedRights -like "*Send-As*"}
[PS] C:\> Get-MailPublicFolder | ?{$_.GrantSendOnBehalfTo -ne "$null"} | Format-Table name,GrantSendOnBehalfTo

To grant these permissions in Exchange Online, use the following example commands in Exchange Online PowerShell:

[PS] C:\> Add-RecipientPermission -Identity <Public Folder> -Trustee <User> -AccessRights SendAs
[PS] C:\> Set-MailPublicFolder -Identity <Public Folder> -GrantSendOnBehalfTo <User>

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:

[PS] C:\> Add-PublicFolderClientPermission -Identity "\publicfoldername" -User "Anonymous" -AccessRights CreateItems


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.

Multiple mailbox users match identity “Mailbox1”

So I’m working on a nice Public Folder migration from Exchange 2016 to Exchange Online. Last week all preparations were performed and this morning I was planning to start the migrationbatch. Fourteen Public Folder mailboxes in Exchange 2016 to eighteen Public Folder mailboxes in Exchange Online. What could possibly go wrong….

Creating the new endpoint for the migrationbatch failed with an error saying “Multiple mailbox users match identity “PFMailbox1″. Specify a unique value” as shown in the following screenshot:

Or in plain text:

PS C:\PFScripts> $PfEndpoint = New-MigrationEndpoint -PublicFolder -Name PublicFolderEndpoint -RemoteServer $Source_RemoteServer -Credentials $Source_Credential
Multiple mailbox users match identity "Mailbox1". Specify a unique value.
    + CategoryInfo          : NotSpecified: (:) [New-MigrationEndpoint], MigrationPermanentException
    + FullyQualifiedErrorId : [Server=AM0PR09MB2402,RequestId=bccebc4f-d231-41d3-b8fe-a676311b3575,TimeStamp=22-8-2022 09:33:52] [FailureCategory=Cmdlet-MigrationPermanentException] 80069390,Microsoft.Exchange.Management.Migration. MigrationService.Endpoint.NewMigrationEndpoint
    + PSComputerName        :
PS C:\PFScripts>

This is strange since there’s no mailbox user named “Mailbox1”, there’s only one Public Folder mailbox named “Mailbox1” and that is holding the Public Folder hierarchy. But, last week I have been preparing the Public Folder migration, and one step was to create a Public Folder mailbox, just to see if it would work. I deleted the Public Folder mailbox, but it is a soft deleted state, and this conflicts with the creation of the Public Folder migration endpoint.

To find the Public Folder mailboxes including the soft deleted mailboxes, execute the following command against Exchange Online:

PS C:\PFScripts> Get-Recipient  -IncludeSoftDeletedRecipients -RecipientTypeDetails publicfoldermailbox | fl Name, OrganizationalUnit, DistinguishedName, ExchangeGuid

It will return a list of Public Folder mailboxes, including the ones in a soft deleted state. Clearly visible in the following screenshot is the soft deleted Public Folder mailbox:

Use the following command against Exchange Online to remove the soft deleted Public Folder mailbox:

[PS] C:\> Remove-Mailbox -PublicFolder "<ExchangeGuid>" -PermanentlyDelete

Wait some time for replication to happen in EXODS and try again to create the Public Folder migration endpoint. This time it succeeded.

Exchange Security Updates August 2022

On August 9, 2022 Microsoft has released important Security Updates for Exchange 2013, Exchange 2016 and Exchange 2019 that are rated ‘critical’ (Elevation of Privileges) and ‘important’ (Information Disclosure).

This security update rollup resolves vulnerabilities found in Microsoft Exchange Server. To learn more about these vulnerabilities, see the following Common Vulnerabilities and Exposures (CVE):

  • CVE-2022-21979 – Microsoft Exchange Information Disclosure Vulnerability
  • CVE-2022-21980 – Microsoft Exchange Server Elevation of Privilege Vulnerability
  • CVE-2022-24477 – Microsoft Exchange Server Elevation of Privilege Vulnerability
  • CVE-2022-24516 – Microsoft Exchange Server Elevation of Privilege Vulnerability
  • CVE-2022-30134 – Microsoft Exchange Server Elevation of Privilege Vulnerability

This Security Update introduces support for Extended Protection. Extended protection enhances authentication to mitigate ‘man in the middle’ attacks. Extended protection is supported on the latest version of Exchange 2016 and Exchange 2019 (2022H1) and the August 2022 Security Update (this one) so it is vital to bring your Exchange servers up-to-date. 

Be aware of the following limitations:

  • Extended protection is only supported on the current and previous versions of Exchange (i.e. Exchange 2016 CU21/CU21 and Exchange 2019 CU12/CU11) and Exchange 2013 CU23 with the August 2022 SU installed
  • Extended protection is not supported on hybrid servers with the hybrid agent.
  • Extended protection is not supported with SSL Offloading. SSL Re-encrypt (also knows as SSL Bridging) is supported, as long as the SSL certificate on the load balancer is identical to the SSL certificate on the Exchange servers.
  • If you still have Exchange 2013 in your environment and you are using Public Folders, make sure your Public Folders are hosted on Exchange 2016 or Exchange 2019.

Note. Make sure you have your Exchange server properly configured with all related security settings. Use the latest HealthChecker.ps1 script to find any anomalies in your Exchange configuration. If you fail to do so, the script to enable Extended Protection will fail with numerous error messages.

Enable Extended Protection

First off, make sure you have the latest Cumulative Update installed on all your Exchange servers and install the August 2022 Security Updates on all your servers, including the Exchange 2013 servers.

Another important thing is that you must make sure that TLS settings across all Exchange servers are identical. You can use the healthchecker.ps1 script to figure out if this is the case. Personally, it took me quite some time to get this right.

The easiest way to configure Extended Protection is by using the ExchangeExtendedProtectionManagement.ps1 script (which can be found on github). This script can enable Extended Protection on all Exchange servers in your organization, but by using the -SkipExchangeServerNames option you can exclude certain Exchange servers (for example, Exchange 2013 servers or servers running the hybrid agent). There’s also the -ExchangeServerNames option which lets you specify which servers to enable the Extended Protection on.

More information and downloads can be found here:

Exchange versionDownloadKB article
Exchange 2013 CU23
Exchange 2016 CU22
Exchange 2016 2022H1
Exchange 2019 CU11
Exchange 2019 2022H1
Exchange Protection Script
Healthchecker scripts

Some important notes:

  • As always, make sure you thoroughly test this in your lab environment, especially enabling Extended protection.
  • You can start the SU from a command prompt or from Windows Explorer, no need anymore to start from a command prompt with elevated privileges.
  • This SU contains all security updates from previous SUs for this particular Exchange version.

Export-ExchangeCertificate not accepting -FileName option

As long as I can remember I have been creating, updating, renewing, exporting and importing Exchange certificates on Exchange servers.

This morning I had to renew my own Exchange certificate, and my PowerShell command Export-ExchangeCertificate failed on the -FileName option so it would not accept the option to store the file somewhere. This is strange, because in our Exchange 2016/2019 book that was released less then a year ago we were able to use the -FileName option.

It turned out that for the Export-ExchangeCertificate and Import-Certificate the -FileName option was removed because of security concerns. In more detail, the -FileName option accepts a UNC path which makes it possible for compromised servers to access other servers using UNC paths.

The way to export a certificate in Exchange 2016 CU23 and Exchange 2019 CU12 (and higher) is to import the certificate in a variable and store this in a file:

[PS] C:\> $Cert = Export-ExchangeCertificate -BinaryEncoded -Thumbprint <Thumbprint> -BinaryEncoded -Password (ConvertTo-SecureString -String 'Pass1word' -AsPlainText -Force)
[PS] C:\> [System.IO.File]::WriteAllBytes('C:\Install\CertExport.pfx', $Cert.FileData)

For importing certificates it is similar, the -FileName is removed from the commandlet in Exchange 2016 CU23 and Exchange 2019 CU12 (and higher), and the -FileData needs to be used:

[PS] C:\> Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path "<local or UNC path>" -Encoding byte)) -Password (ConvertTo-SecureString -String 'Pass1word' -AsPlainText -Force)

Note. For Exchange 2013 server the -FileName option can still be used.

More information can be found on and

Exchange 2016 and Exchange 2019 SMTP Relay

The last couple of days I have been working with multiple customers on SMTP relay in Exchange 2016 during a migration from Exchange 2010 to Exchange 2016. The last time I did that was with Exchange 2010, almost 9 years ago and things have changed over the years. The changes in Exchange 2016 are carried forward in Exchange 2019…. Oh, and this is true for Exchange 2013 as well, but since Exchange 2013 is already out of support and none of my customers is using Exchange 2013 I’ll skip this….

Exchange 2010 has the Hub Transport service for SMTP, and this is using port 25 for communicating with other SMTP hosts. Exchange 2016 and Exchange 2019 have two services for SMTP transport:

  • Front-End Transport service (FETS) listening on port 25. This is where other SMTP hosts connect to. In the Exchange 2016 Admin Center the FETS Receive Connector is identified as Default Frontend <server> . In Exchange 2013, this service was running on the Client Access Server.
  • Hub Transport Service listening on port 2525. This is a back-end service used by FETS and other Exchange Hub Transport back-end services. Clients are not expected to use the Hub Transport service on port 2525. In the Exchange Admin Center this Receive Connector is identified as Default <server> . In Exchange 2013, this service was running on the Mailbox server.

These connectors are shown in the following screenshot. The Default Frontend Receive Connector (on port 25) is selected, the red arrow points to the Hub Transport Receive Connector on port 2525.

Note. The Client Frontend Receive Connector in the screenshot is listening on port 587 and is used for authenticated SMTP clients like Mozilla Thunderbird.

SMTP Relay in Exchange 2016 and 2019

The Default Frontend Receive Connector allows all SMTP clients to connect to it and drop email messages for local delivery. You don’t want to configure this connector to relay SMTP message to external domains, this is known as an ‘open relay’ and this is the number one reason to be put on every blacklist available on the Internet. You can do this and restrict access based on IP addresses, but I strongly recommend against changing the default connectors. Leave the inbound SMTP traffic end up on the Default Frontend Receive Connector and create a dedicated connector for SMTP relay traffic.

There are two ways to create such a relay connector:

  • Create a dedicated receive connector (on Frontend Transport, not on Transport Service), restrict by IP address and add the Ms-Exch-SMTP-Accept-Any-Recipient permission on the NT AUTHORITY\ANONYMOUS LOGON security principal. This is what I have shown in the blog mentioned earlier, and this is only possible using Exchange PowerShell. Sending hosts are considered anonymous, and anti-spam and message size limits are applied.
  • Create a dedicated receive connector (again on the Frontend Transport), restrict by IP address, and add the Exchange Servers and Externally Secured authentication mechanism to the connector. In this scenario, sending hosts are considered as authenticated senders, and email messages bypass anti-spam and message size limits. And it’s easy to configure using the Exchange Admin Console.

Since the first option is already documented, I will continue with the second option. Personally, I like to do this with PowerShell and the command to create such a connector and configure it are like these:

[PS] C:\>New-ReceiveConnector -Name "SMTP Relay EXCH01" 
-Server EXCH01 -TransportRole FrontendTransport -Custom 
-Bindings -RemoteIpRanges

Identity                 Bindings     Enabled
--------                 --------     -------
EXCH01\SMTP Relay EXCH01 {} True

[PS] C:\>Set-ReceiveConnector "EXCH01\SMTP Relay EXCH01" 
-AuthMechanism ExternalAuthoritative 
-PermissionGroups ExchangeServers

[PS] C:\>

When you check the connector using the Exchange Admin Center, you can see that the authentication mechanism is set correctly as shown in the following screenshot:

It is also possible to create a new connector using the Exchange Admin Center. In the EAC, navigate to mail flow and select the receive connectors tab and click the + icon. Follow the wizard, give the new connector a proper name, select Frontend Transport and Custom, and restrict by IP address as shown in the following screenshots:

When created, open the new receive connector, select security and configure the authentication mechanmism to Externally secured and Exchange servers as shown in a previous screenshot.

It is now possible to relay SMTP messages from the server with IP address Using Telnet on port 25, you will see something like this:

When trying to relay from another server (which is not listed in the Remote Network Settings) it will fail with the 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain error as shown in the following screenshot:


So in short, do not configure the default receive connector in such a way that it will relay messages outside of the Exchange server. When you need to use SMTP relay, create a dedicated connector.

The first and most secure option is to create a new receive connector, restrict by IP address and configure the Ms-Exch-SMTP-Accept-Any-Recipient permission. Anti-spam and message size limits are applied, but it can only be configured using PowerShell (and thus more complex).

The second on is to create a new receive connector, restrict by IP address and configure the authentication mechanisms. Easier to configure (using EAC) but less secure: anti-spam and message limits are not applied.

It is up to you which one to use.