Announcing the support for modern public folder migrations without dumpster data

Published Jun 20 2018 07:49 AM 6,540 Views

Long time Exchange administrators will remember that Exchange Server had a feature that was for a while unceremoniously referred to as the “dumpster”. We have since renamed the feature to a more descriptive Recoverable Items Folder. This blog post also contains a bit of history of this feature for those interested. Up to now, during public folder migration, all the public folder data including dumpsters was migrated from on-premises servers to the cloud. Administrators did not have an option to exclude this data at migration. We are introducing the ability to migrate public folders to cloud without migrating the dumpster data. To do this, administrators need to pass the ExcludeDumpsters parameter while creating the migration batch. This option can be used when source server version is Exchange 2013 or 2016. Here is an example of how to use this parameter:

New-MigrationBatch -Name PublicFolderMigration -CSVData $bytes -SourceEndpoint $PfEndpoint.Identity -ExcludeDumpsters

Note: Please do not use -ExcludeDumpster parameter if you expect users or admins to restore deleted public folders during the migration. The migration batch will fail with error “ErrorFoldersRestoredDuringMigrationPermanentException” if users/admins restore deleted public folder while migration is still in progress. See this article for more information.

Why would you want to do this?

Excluding this data can help you scale your public folder migration if you do not need the data to come over. This will result in faster public folder migration as the amount of data that will need to be migrated is going to be smaller. To check the dumpster folders size, you can run the following:

Get-PublicFolder \NON_IPM_SUBTREE\DUMPSTER_ROOT -Recurse -ResultSize:unlimited | ?{$_.FolderClass -ne "$null"} | ft name,foldersize

In addition to size consideration, we have seen some organizations where dumpster data got corrupted (for various reasons) and administrators did not want that corrupted data migrated to cloud. If you find yourself in that situation, this feature will enable you to leave that data behind. The obvious drawback to doing this is that users will lose the ability to recover items that were previous deleted from public folders (pre-migration).

Note: The ExcludeDumpsters parameter is optional and if not passed to migration batch, all dumpsters will migrate to cloud. Once you choose to exclude dumpsters and the migration is finalized, there is no way to go back and re-include the dumpsters into cloud public folders. If, during the migration in which you used the ExcludeDumpsters parameter, you decide that you do want to migrate the dumpsters data to the cloud, remove the current migration batch and create another without the ExcludeDumpsters parameter.

This option can be added at point 4 of Step 7 in below TechNet articles for public folder migration (we will work to change the documentation next):

Keep checking this blog for further updates on the subject! In case of any questions, please do reach out to us via the comments section below.

Public folder team

Not applicable
What is the expected behavior if someone recovers/restores a deleted public folder from the dumpster during the synchronization process (prior to cut over), if the batch was created using the -ExcludeDumpsters parameter? Is this supported, or will there be any impact to the PublicFolderMailboxMigrationRequest?
Not applicable
if the dumpster is excluded and user recovers a folder from dumpster. you will see a message in migration report a new folder was recovered with folder path for admin to do the need full action with that folder.
New Contributor

There is nothing more frustrating then stumbling upon broken links in technical documentation while trying to initiate a migration.  


The link "Use batch migration to migrate Exchange 2013 public folders to Exchange Online" points only to a web-based middle finger (404).



New Contributor

Let me take a crack at technical documentation.


If you receive transient failures indicating "DumpsterOfDumpsterFolderMissingTransientException has occurred.":

1. Follow an unbroken link to the Batch Migration steps document.

2. Begin at un-numbered step;  Heading "Prerequisite steps in Exchange Online";  remove everything you just spend hours on.

Get-MigrationBatch | ?{$_.MigrationType.ToString() -eq "PublicFolder"}

Remove-MigrationBatch <batchname> -Confirm:$false

3. Skip to sub-step 4;  to remove the public folder mailboxes:
$hierarchyMailboxGuid = $(Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid
Get-Mailbox -PublicFolder | Where-Object {$_.ExchangeGuid -ne $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -Confirm:$false -Force
Get-Mailbox -PublicFolder | Where-Object {$_.ExchangeGuid -eq $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -Confirm:$false -Force
Get-Mailbox -PublicFolder -SoftDeletedMailbox | % {Remove-Mailbox -PublicFolder $_.PrimarySmtpAddress -PermanentlyDelete:$true -force}


4.  Skip to Step 4:  Create the public folder mailboxes online.   Be sure to copy the commands to notepad first, or else you'll create new mailboxes that don't include the mappings - as carriage returns are included in the script commands.   Re-run your commands from above if you poo'd this up.


Continue down the document, Creating your public folders from on-prem.  


In sub-step 5 (In Exchange Online PowerShell, run the following commands to create the public folder migration endpoint and the public folder migration request), copy the commands to notepad.   Edit the "New-MigrationBatch" command to include the "-ExcludeDumpsters" switch.


If the "$PFEndpoint = New-MigrationEndpoint" command errors out with: "Cannot find a recipient that has mailbox GUID 'guid', then have a coffee, a smoke, or what have you.   The power of the cloud has not yet updated your recipient list with the GUID of the new PFmailbox yet.   Early today, this took 45 minutes of trying until it was successful.   ahhhh...billable time.   Just keep on trying.  It is the cloud, and yes - it will drive you to insanity.  (Ironically, our local hospital's psyc-hold is actually on the top floor - bringing you even closer to the cloud).


Coffee's gone;  attempt #5 - no dice.  Might as well go pee and refill.

Back.  Another whirl, and.....Bah!  Nope.  Pondering taking lunch, but really need to get this kicked off, as first availability to lockdown the folders is at 5pm, and it's 12:48 now.   


10 minutes have gone by (albeit slowly) - so try #7 - still not there.   Ok.   Lunch it is.


Back from lunch; and after all of this, there's already a migration endpoint still defined.   All this time we should have changed our New-MigrationBatch command to:

New-MigrationBatch -Name PublicFolderMigration -CSVData $bytes -SourceEndpoint PublicFolderEndpoint   . . . . .


Although, given the recipient creation time-warp issue, I'm sure that error would still throw, even when attempting the New-MigrationBatch command.


and WALLA!!

Identity Status Type TotalCount
-------- ------ ---- ----------
PublicFolderMigration Syncing PublicFolder 2


Name StatusDetail TargetMailbox PercentComplete
---- ------------ ------------- ---------------
PublicFolderMailboxMigration910dab6c-f3a0-494... Synced PFMailbox2 95
PublicFolderMailboxMigration80abd8d5-b595-4ca... CopyingMessages PFMailbox1 27


Hopefully this helps anyone who gets the "DumpsterOfDumpster" errors when migrating.  


Thanks for following along and happy weekend!





Occasional Visitor

@bryannsoThank you so much for "If the "$PFEndpoint = New-MigrationEndpoint" command errors out with: "Cannot find a recipient that has mailbox GUID 'guid', then have a coffee, a smoke, or what have you."  I was pulling my hair out and found very little online until I finally found your comment.  Waiting longer of course worked.


re: links, try

New Contributor

You're much welcome!   I was hoping this would get indexed (the DumpsterOfDumpsterFolderMissingTransientException).

Version history
Last update:
‎Feb 04 2021 06:10 AM
Updated by: