Blog Post

Exchange Team Blog
4 MIN READ

Troubleshooting Public Folder Deletion Issues in Exchange Online

The_Exchange_Team's avatar
May 11, 2023

Public folders provide a way to collect, organize, and share information with other people in your organization. They can help users organize content in a deep hierarchy that's easy to browse in Outlook and Outlook on the web (OWA).

This blog post is here to help admins troubleshoot deletion issues with public folders, with a focus on the following scenarios:

  • A user with sufficient permissions (for example, folder Owner) is unable to delete items within a public folder. After content is deleted using OWA or Outlook, it re-appears within a few seconds.
  • A user with sufficient permissions (for example, Exchange administrator) is unable to delete a public folder and its content using PowerShell / Exchange Admin Center (EAC) and is getting one of the following errors:
    • Microsoft.Exchange.Data.StoreObjects.ObjectNotFoundException: Could not find public folder Dumpster for \PF1
    • Microsoft.Exchange.Data.StoreObjects.ObjectNotFoundException: The process failed to get the correct properties. ---> Microsoft.Mapi.MapiExceptionNotFound: MapiExceptionNotFound: Unable to get properties on object

These issues can occur when the public folder dumpster is invalid or does not exist. The exact reason for this might not be known, but the issue typically happens after public folders are migrated from on-premises servers using PSTs or third-party migration tool.

What is the Dumpster Folder?

Today’s public folder storage model uses a visible “IPM_SUBTREE” part that contains public folders and their content, and a hidden area called the “NON_IPM_SUBTREE” that which contains dumpster folders and other system related folders.

Every content folder has a dumpster folder where deleted items are retained according to the defined retention time. Once the retention time has elapsed, the items are permanently purged.

Example:

As illustrated here, deletion of public folder content is really a content move from the visible folder to the dumpster:

Each folder and its dumpster are linked to each other. This link cannot be undone, and admins cannot delete dumpster folders by themselves. When a folder is removed from the public folder hierarchy, its dumpster is automatically removed. The same principle applies to mailbox folders and subfolders, too.

Addressing public folder/item deletion failures

A newly published PowerShell-based tool, ValidateEXOPFDumpster, can help you investigate public folders/items deletion failures. The tool validates the following:

  • Public folder size
    • Public folder content mailbox TotalDeletedItemSize value has exceeded its RecoverableItemsQuota value
    • Public folder size is full
  • User permissions are not synced between public folder mailboxes
  • Content public folder mailbox between the public folder and its dumpster are different
  • EntryId and DumpsterEntryID values are not mapped properly on the public folder and its dumpster
  • Parent public folder dumpster is unhealthy
  • The public folder is a dumpster folder
  • Dumpster folder has child folders
  • Mail-enabled public folder MEPfProxyGuid is “null”

The ValidateEXOPFDumpster script is not officially supported by Microsoft support. For any issues related to this script, please file a GitHub request with the Exchange Tools team or email ExToolsFeedback[AT]microsoft[DOT]com.

How does the tool work?

Typically, the tool is run with a PFolder parameter specifying the public folder identity as follows:

 

 

.\ValidateExoPfDumpster.ps1 -PFolder \pf1

 

 

The tool will prompt for affected public folder identity/EntryID if it wasn't provided using PFolder parameter and then it will prompt for Exchange administrator username and password to connect to Exchange Online. By default, the tool assumes that the issue being investigated is impacting to a specified public folder but all users are affected.

If the deletion issue happens only for a specific user, the user’s SMTP address can be provided as follows:

 

 

.\ValidateExoPfDumpster.ps1 -PFolder \pf2 -Affecteduser user@contoso.com

 

 

The tool will generate the public folder validation checks failures and proposed fixes results on the screen and will generate the ValidatePFDumpsterREPORT.txt file, as well. There are other files generated for either logging purposes or for logs to be shared with Microsoft support.

File Name

Content

Use

ValidatePFDumpsterREPORT.txt

Information about any issues found

The tool displays what it found, and in many cases, it provides a solution to fix the problem

ValidatePFDumpsterChecksLogging.csv

Information about the reason of tool run failure

The file will display errors encountered during running of the tool and at which stage it failed

PublicFolderInfo.xml

All required information about the affected public folder

Shared with Microsoft support if engaging support about this problem

Let’s check the following examples to get more clarification on how the tool works.

Example1: Running the tool on the affected public folder “\pf2” where only one user is affected (user@(domain).com). 

The tool points out two issues:

  • Neither the specified user nor the default user have sufficient permissions to delete items inside the public folder
  • Public folder size has exceeded the Individual Public Folder ProhibitPostQuota value

Example2: Running the tool on the affected public folder “\t” where all users are affected

The tool points out the following:

  • Public folder and its dumpster don't have the same content public folder mailbox
  • Public folder EntryId and DumpsterEntryID values are not mapped properly
  • Public folder size has exceeded Organization DefaultPublicFolderProhibitPostQuota value
  • Public folder dumpster has 1 subfolder

The tool also creates a log file containing all the required information "PublicFolderInfo.xml" to be shared with Microsoft support, if needed, and has provided mitigation for the last two issues.

Special thanks to Bhalchandra Atre and Nino Bilic who reviewed and contributed to this post.

Hazem Embaby
Support Escalation Engineer

Updated May 22, 2023
Version 3.0

6 Comments

  • Hello Alex_Scerus ,

     

    Please find my replies inline.

     

    This should be clearly mentioned within the official migration docs and in here -> Yes I can work to post them on our official article after confirming this information with public folder engineering team.

    It looks like that we are currently having issues hierarchy sync issues… and my feeling is that this is being caused by the size of the hierarchy and the number of mailboxes trying to pull the hierarchy from the primary hierarchy. -> Normal to have if you have huge hierarchies and if you have more than 100 public folder mailbox you can expect to see hierarchy read replace public folder mailboxes which is acting as a middle tier between secondary public folder mailbox es and your root public folder mailbox to avoid any over-exhaustion on your root primary public folder mailbox. https://techcommunity.microsoft.com/t5/exchange-team-blog/help-us-scale-public-folder-hierarchy-in-exchange-online/ba-p/922664

    So, I am interested in the relationship between the different attributes, sync states in PF diagnostic logs, conditions, which will trigger a Public Folder mailbox to become HierarchyReady and being offered to the end-user. -> The conditions is when IsHierarhcyReady set to True and IsExcludedfromServingHierarchy is set to False and that is described on the article.

    https://techcommunity.microsoft.com/t5/exchange-team-blog/modern-public-folder-deployment-best-practices/ba-p/606172

    If the PublicFolderInvalidDumpsterFixingProcessor created and attached 242k “dumpster” right after the migration… my understanding is that this also is some kind of hierarchy change, which has to be replicated to every pf mailbox? -> Yes it's, to update DumpsterEntryID across all requested PublicFolders

    Let me know if you have further concerns.

     

    Regards,

    Hazem

     

  • Alex_Scerus's avatar
    Alex_Scerus
    Copper Contributor

    Hi Hazem_Embaby 

     

    Thank you for the info’s.

     

    I was aware about the docs you linked, except the PublicFolderInvalidDumpsterFixingProcessor (and the others not officially documented).

    Here it is mentioned that "The exact reason for this might not be known, but the issue typically happens after public folders are migrated from on-premises servers using PSTs or third-party migration tool."

    In fact, now it sounds 'logical' that a migration done with "-excludedumpsters" will cause the PublicFolderInvalidDumpsterFixingProcessor to touch every folder after the migration.

    This should be clearly mentioned within the official migration docs and in here. (not only referring to pst and/or 3rd party tool migrations)

     

    Right after the migration (using -excludedumpsters for ~242k Public folders in 100 source PF mailboxes) all target PF mailboxes were IsExcludedFromServingHierarchy:$false (except the primary hierarchy) and IsHierarchyReady:$true.

    But checking the hierarchy after the migration (as described in “Introduction to Public Folder Hierarchy Sync”) showed that almost no PF mailbox was in sync, even the attribute IsHierarchyReady was $true.

     

    It looks like that we are currently having issues hierarchy sync issues… and my feeling is that this is being caused by the size of the hierarchy and the number of mailboxes trying to pull the hierarchy from the primary hierarchy.

     

    So, I am interested in the relationship between the different attributes, sync states in PF diagnostic logs, conditions, which will trigger a Public Folder mailbox to become HierarchyReady and being offered to the end-user.

     

    If the PublicFolderInvalidDumpsterFixingProcessor created and attached 242k “dumpster” right after the migration… my understanding is that this also is some kind of hierarchy change, which has to be replicated to every pf mailbox?

     

    Regards

    Alex

     

     

  • Hello Alex_Scerus,

     

    The process you mentioned is related to a new processor that was rolled out to the service to fix public folder dumpster issues called "PublicFolderInvalidDumpsterFixingProcessor"

    I assume that this process started, and fixed (almost) *all* folders, since we were migrating without dumpster? Correct?  -> Yes it should have created dumpsters to each migrated public folder and you can verify that using the script mentioned here.

    Does this mean that, more or less, the complete hierarchy was being changed by this process? -> The processor has just created and attached dumpster folders for each migrated public folder to handle/store deleted items inside.

     

    Right now we are facing issues described above (e.g. folders, items can't be deleted) and it seems that the hierarchy sync has troubles to sync the mailboxes serving the hierarchy. -> for the 1st part might be that PublicFolderInvalidDumpsterFixingProcessor has failed to create dumpsters for your migrated public folders so as a result we involve our product engineering team to investigate & fix that matter since, in regards to the 2nd part what kind of troubles are you referring to?

    Additional it would be nice to learn more about all processes... what, when, how, since it looks like those are not well documented, additionally it seems that MS support is also not aware of this stuff: -> Not all these processors are documented I'll the add below what is publicly existing, hope that helps.

    PublicFolderHierarchySyncProcessor -> https://techcommunity.microsoft.com/t5/exchange-team-blog/introduction-to-public-folder-hierarchy-sync/ba-p/609344
    PrimaryPublicFolderMailboxProcessor 
    PublicFolderItemProcessor 
    PublicFolderDiscoveryHoldsProcessor 
    PublicFolderItemProcessor_DueDateForUsageStatistics
    PublicFolderSplitProcessor -> https://techcommunity.microsoft.com/t5/exchange-team-blog/how-exchange-online-automatically-cares-for-your-public-folder/ba-p/2050019
    PublicFolderMailboxRemovalProcessor 
    PublicFolderMailboxMaintenanceProcessor
    PublicFolderInvalidPermissionsCleanUpProcessor -> https://techcommunity.microsoft.com/t5/exchange-team-blog/announcing-the-public-folder-consistency-agent-for-exchange/ba-p/609273
    PublicFolderInvalidDumpsterFixingProcessor -> mentioned here

     

    Let me know if you have further concerns.

     

    Regards,

    Hazem

  • Alex_Scerus's avatar
    Alex_Scerus
    Copper Contributor

    Hazem_Embaby 

     

    Can you please give us a little bit more insights regarding EXO processes handling this issue and possible other stuff regarding Public Folder? (e.g. PublicFolderInvalidDumpsterFixingProcessor)

    Recently, we had a Public Folder migration (close to 250k folders) to EXO and we are still facing issues. (MS Case still open)

    This seems to be related to fact we had to migrate with the -ExcludeDumpsters switch due to the amount of folders.

    After the batch was completed, we had issues during testing and after some investigation it looked like that some process started, touching all public folders.

    Example from the Auditlog:

    $audit = search-AdminAuditLog -StartDate (get-date).AddHours(-1) -EndDate (get-date) -ResultSize 250000
    $audit | group CmdletName | sort name | select count,name
    
    Count Name
    ----- ----
      345 Set-PublicFolder
    8518 Update-PublicFolderMailbox
    
    
    Example of Update-PublicFolderMailbox Audit Event:
    
    ObjectModified     : PrimaryHierarchyPFMBX
    CmdletName         : Update-PublicFolderMailbox
    CmdletParameters   : {Identity, InvokeSynchronizer, FolderId, CreateAssociatedDumpster}
    ModifiedProperties : {}
    Caller             : NT AUTHORITY\SYSTEM (MSExchangeMailboxAssistants)
    ExternalAccess     : False
    Succeeded          : True
    IsValid            : True
    ObjectState        : New

    I assume that this process started, and fixed (almost) *all* folders, since we were migrating without dumpster? Correct?

    Does this mean that, more or less, the complete hierarchy was being changed by this process? (keeping in mind that we migrated without dumpster)

    Right now we are facing issues described above (e.g. folders, items can't be deleted) and it seems that the hierarchy sync has troubles to sync the mailboxes serving the hierarchy.

    Additional it would be nice to learn more about all processes... what, when, how, since it looks like those are not well documented, additionally it seems that MS support is also not aware of this stuff:

    PublicFolderHierarchySyncProcessor
    PrimaryPublicFolderMailboxProcessor
    PublicFolderItemProcessor
    PublicFolderDiscoveryHoldsProcessor
    PublicFolderItemProcessor_DueDateForUsageStatistics
    PublicFolderSplitProcessor
    PublicFolderMailboxRemovalProcessor
    PublicFolderMailboxMaintenanceProcessor
    PublicFolderInvalidPermissionsCleanUpProcessor
    PublicFolderInvalidDumpsterFixingProcessor

     

    Regards

    A.

  • Hello ,

    There's a new ValidateExoPfDumpster script release with extra new features/fixes:

    • Support for ExchangeOnlineManagemnt V3 PowerShell module.
    • New check for public folder dumpster corruption.
    • Fix UI issues.
    • Fix reported issue in PowerShell 7.

    Your feedback is highly appreciated for always optimizing the script.

  • Thanks Hazem and dpaulson45 for the script and the explanation 🙂