[Issue] SourceSideValidations - "Index operation failed" for DumpsterEntryID

[PeterNagl]

I recently had the following error in SourceSideValidation script.

[PS] D:\PF2Cloud>.\SourceSideValidations.ps1
Added job Get-IpmSubtree to queue.
Added job Get-NonIpmSubtree to queue.
Added job Get-Statistics to queue.
Started executing job Get-IpmSubtree.
Started executing job Get-NonIpmSubtree.
Started executing job Get-Statistics.
Get-NonIpmSubtree job finished.
Get-IpmSubtree job finished.
Get-Statistics job finished.
Get-FolderData duration 01:08:04.0517631
IPM_SUBTREE folder count: 36977
NON_IPM_SUBTREE folder count: 35780
SourceSideValidations 25.07.23.2047 complete. Total duration 01:08:13.3173147

Liked the script or had a problem? Let us know at ExToolsFeedback@microsoft.com
Test-DumpsterValid : Index operation failed; the array index evaluated to null.
At D:\PF2Cloud\SourceSideValidations.ps1:189 char:23
if (-not (Test-DumpsterValid $_ $FolderData)) {
CategoryInfo : InvalidOperation: (:) [Test-DumpsterValid], RuntimeException
FullyQualifiedErrorId : NullArrayIndex,Test-DumpsterValid

File Output, the Result File is missing.

In IpmSubtree.csv and NonIpmSubtree.csv some DumpsterEntryIDs that are empty.

Github Autopilots solution:

Summary

Fixed a null-indexing bug that caused: "Index operation failed; the array index evaluated to null."
File changed: sourcesidevalidation.ps1
Function changed: Test-DumpsterValid (inside Test-DumpsterMapping) — now guards against a null DumpsterEntryId before indexing NonIpmEntryIdDictionary.
What I changed

Previously the code did:
$dumpster = $FolderData.NonIpmEntryIdDictionary[$Folder.DumpsterEntryId]
which throws when $Folder.DumpsterEntryId is null.
I updated it to only index when DumpsterEntryId is not null/empty:
If DumpsterEntryId is null/empty, $dumpster stays $null.
The existing validation then marks the mapping invalid as intended (same end result, but no exception).
Why this fixes your error

The PowerShell error you saw happens when code tries to index a hashtable/array using a null key. The guard prevents that and preserves the intended logic (folders without a valid dumpster mapping will be flagged invalid rather than crash the script).

$dumpster = $null
if (-not [string]::IsNullOrEmpty($Folder.DumpsterEntryId)) {
$dumpster = $FolderData.NonIpmEntryIdDictionary[$Folder.DumpsterEntryId]
}

Changed Test-DumpsterMapping function

function Test-DumpsterMapping {
[CmdletBinding()]
[OutputType([System.Object[]])]
param (
[Parameter()]
[PSCustomObject]
$FolderData
)

begin {
    function Test-DumpsterValid {
        [CmdletBinding()]
        [OutputType([bool])]
        param (
            [Parameter()]
            [PSCustomObject]
            $Folder,

            [Parameter()]
            [PSCustomObject]
            $FolderData
        )

        begin {
            $valid = $true
        }

        process {
            $dumpster = $null
            if (-not [string]::IsNullOrEmpty($Folder.DumpsterEntryId)) {
                $dumpster = $FolderData.NonIpmEntryIdDictionary[$Folder.DumpsterEntryId]
            }

            if ($null -eq $dumpster -or
                (-not $dumpster.Identity.StartsWith("\NON_IPM_SUBTREE\DUMPSTER_ROOT", "OrdinalIgnoreCase")) -or
                $dumpster.DumpsterEntryId -ne $Folder.EntryId) {

                $valid = $false
            }
        }

        end {
            return $valid
        }
    }

After running the script with the fix, it went through smoothly, customer happy.

After looking up the DumpsterEntryID, it should also be possible to repair the Dumpster mapping with:
https://techcommunity.microsoft.com/blog/exchange/troubleshooting-public-folder-deletion-issues-in-exchange-online/3819379

In that case, a warning message in the report with a link to the fix would be great.

kind regards
Peter