When normal file accounting fails to explain disk usage, Volume Shadow Copy Service (VSS) snapshots are often the invisible space consumers. Your vssadmin List Shadows output reveals multiple ApplicationRollback-type shadows that resist standard deletion attempts.

The error Snapshots were found, but they were outside of your allowed context indicates these are application-created snapshots (likely from Exchange Server given the hostname). These differ from system restore points in their persistence attributes:

Attributes: Persistent, No auto release, Differential, Exposed locally, Auto recovered

For stubborn snapshots, try this PowerShell sequence:

# First attempt standard deletion
vssadmin delete shadows /all /quiet

# If that fails, identify locked snapshots
Get-WmiObject Win32_ShadowCopy | ForEach-Object {
    $_.Delete()
}

# For Exchange-created snapshots specifically
Add-PSSnapin Microsoft.Exchange.*
Remove-MailboxDatabaseCopy -Identity "YourDatabaseName" -Confirm:$false

Configure VSS properly for Exchange environments:

# Recommended VSS settings for Exchange
Set-MailboxServer -Identity YourServer 
    -DatabaseCopyAutoActivationPolicy Blocked 
    -MaximumActiveDatabases 1 
    -ShadowCopyVolumeConfiguration "*:03:00,07:00"

When VSS isn't the issue, consider these deeper scans:

# WinDirStat alternative for programmers
choco install wiztree -y
wiztree /export=c:\space_report.csv /admin=1

# PowerShell deep scan
Get-ChildItem -Path C:\ -Recurse -Force -ErrorAction SilentlyContinue | 
    Where-Object { $_.PSIsContainer -eq $false } | 
    Sort-Object -Property Length -Descending | 
    Select-Object -First 50 FullName, Length | 
    Export-Csv -Path "c:\large_files.csv"

Remember that NTFS features like:
- Sparse files
- Alternate data streams
- Cluster size overhead
Can create reporting discrepancies between file properties and actual disk usage.

When your disk space calculations don't add up (visible files + hidden + system ≠ total used space), the culprit is often Volume Shadow Copy Service (VSS) snapshots. These are essentially point-in-time backups created by Windows for system restore and application recovery.

Use PowerShell for comprehensive shadow copy detection:

# List all shadow copies with size estimation
Get-WmiObject Win32_ShadowCopy | ForEach-Object {
    $vol = (Get-WmiObject Win32_Volume -Filter "DeviceID='$($_.VolumeName)'")
    [PSCustomObject]@{
        ID = $_.ID
        Volume = $vol.Name
        Created = $_.InstallDate
        SizeMB = [math]::Round(($_.MaxSpace/1MB),2)
        UsedMB = [math]::Round(($_.UsedSpace/1MB),2)
    }
}

When standard deletion fails with "outside allowed context" errors:

# Force removal of persistent VSS snapshots
$vssAdmin = "$env:SystemRoot\\System32\\vssadmin.exe"
& $vssAdmin delete shadows /for=C: /all /quiet

# Alternative method using DiskShadow
echo "list shadows" > commands.txt
echo "delete shadows all" >> commands.txt
diskshadow /s commands.txt

For Exchange servers (as shown in the logs), special handling is required:

# For Exchange-aware VSS management
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
Get-MailboxDatabase | ForEach-Object {
    if ($_.SnapshotLastFullBackup) {
        Write-Host "Database $($_.Name) has VSS snapshot from $($_.SnapshotLastFullBackup)"
    }
}

After removing shadow copies, force storage reclamation:

# Compact NTFS clusters
defrag C: /U /V

# Reset System Restore points
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10%