Exchange Health Checker: UnifiedContent Auto Cleanup Configured = False

The Exchange Health Checker returns an error if the Exchange Server was not installed in the default path. For example, if the Exchange Server was installed on the D: drive, a path is missing in the configuration for the automatic cleanup of the UnifiedContent directory. The directory then becomes larger and larger and littering the fairgrounde too. This can now be cleaned up automatically if the path for the cleanup is entered accordingly.

If the path to the UnifiedContent directory is missing, Health Checker returns this error:

UnifiedContent Auto Cleanup Configured False
Exchange Health Checker: UnifiedContent Auto Cleanup Configured = False

The path to the directory is entered in the "Antimalware.xml" file. Unfortunately, the entry is reset to the default values when updates are installed. I have therefore created a small script so that you do not have to enter the paths manually in the XML file after each update:

$AntiMalwareXMLPath = $exbin + "Monitoring\Config\AntiMalware.xml"
[xml]$AntiMalwareXML = Get-Content -Path $AntiMalwareXMLPath
$OldValue = $AntiMalwareXML.Definition.MaintenanceDefinition.ExtensionAttributes.CleanupFolderResponderFolderPaths
$NewValue = $exinstall + "TransportRoles\data\Temp\UnifiedContent;" + $OldValue
$AntiMalwareXML.Definition.MaintenanceDefinition.ExtensionAttributes.CleanupFolderResponderFolderPaths = $NewValue
$AntiMalwareXML.Save($AntiMalwareXMLPath)

The PowerShell script can be executed directly in the Exchange Admin Shell. After running the script, Exchange Health Checker no longer returns any errors:

Exchange Health Checker: UnifiedContent Auto Cleanup Configured = False

3 thoughts on “Exchange Health Checker: UnifiedContent Auto Cleanup Configured = False”

  1. Es gibt derzeit auch noch einen Fehler im Exchange Health Checker auf manchen Windows Server 2025:
    „There appears to have been some errors in the script.“ Im HealthChecker-Debug_*.txt steht dann:
    The term ‚Get-EventLogLevel‘ is not recognized as the name of a cmdlet…
    Dieser Fehler wird im nächsten Release des HealthCheckers gefixt, hab ich mit MS geklärt :)

    Reply

Leave a Comment