Exchange-Transportprotokolle werden in einer Hyper-V Umgebung nach erfolgreicher Sicherung nicht abgeschnitten/bereinigt

Microsoft Exchange unterstützt VSS (Volume Shadow Copy Service) basierte Backups. BackupsAssist nutzt die Exchange VSS Writer, um Exchange Datenbanken zu sichern und wiederherzustellen. Exchange installiert dafür einen VSS Writer mit dem Namen “Microsoft Exchange Writer”. (Siehe cmd.exe "vssadmin list writers")

 
Bei einem Backup-Job mit aktivierter Option "Vollständiges VSS-Verfahren" in den Job-Einstellungen unter "Dateien und Ordner" werden die Logs gelöscht:
 
 
Windows-Ereignisanzeige:
 
 
Funktioniert dies nicht, gehen Sie bitte wie folgt vor:
 
Bitte den Hyper-V-Manager öffnen und per Rechtsklick in die Einstellungen der VM wechseln.
Hier in den Integrationsdiensten bitte die Gastdienste aktivieren mit anschließendem Neustart von Hyper-V-Server und Exchange-Server (Gast).  
  
Sie können Gastdienste auch mithilfe des Windows PowerShell-Cmdlets 
aktivieren:
Enable-VMIntegrationService
 
Offensichtlich gab es hier bis Anfang 2015 einen noch nicht behobenen Bug in der Microsoft Server 2012R2 mit Hyper-V Rolle. Dieser sollte mittlerweile behoben sein. 
 
Anderenfalls gehen Sie wie folgt vor:
 
Der Dienst "Hyper-V-Volumenschattenkopie-Anforderungsdienst"  (englische Windows-Version: "Hyper-V Volume Shadow Copy Requestor Service")  muss nach jedem Neustart einer VM mit Exchange einmal beendet und wieder gestartet werden, da sonst die Transaktionsprotokolle nicht bereinigt werden.
 
Weitere Informationen dazu finden Sie im Folgenden: 

Wichtiger Hinweis:

If your Hyper-V host is running Windows Server 2016/2019 and your Exchange VM is running on a Windows Server 2012R2 (or older) operating system, please note that there is a confirmed Microsoft bug. VMs running Windows Server 2012R2 (or older) will not be able to truncate the logs in this case and since Windows Server 2012R2 is in extended support, Microsoft does not release non-security updates. Their recommendation in this case is to update the VM's Operating System to Windows Server 2016 (or newer) in order to avoid such supportability issues.

Should you wish to confirm this with Microsoft, you may feel free to contact them and reference Microsoft Support Case number 118101819243072.