Veeam Repository Firewall Regeln

Um einen Veeam-Repository-Server mit der Veeam Infrastruktur zu verbinden, braucht man ein paar Firewall-Regeln. Die sind zum Glück auch hier ganz gut dokumentiert.

Um mir die Arbeit jedesmal aufs neue zu ersparen 🫡 hier eine schnelle Copypasty für die notwendigen Ports.

Repository-Services, Datamover und NFS-Server:

netsh advfirewall firewall add rule name="VEEAM Repository" dir=in action=allow protocol=tcp localport=2500-3300
netsh advfirewall firewall add rule name="VEEAM Datamover" dir=in action=allow protocol=tcp localport=6162
netsh advfirewall firewall add rule name="VEEAM vPower NFS" dir=in action=allow protocol=tcp localport=6161
netsh advfirewall firewall add rule name="VEEAM Backup Proxy" dir=in action=allow protocol=tcp localport=6160

# Nur wenn Veeam-Agenten auf das Repository sollen
netsh advfirewall firewall add rule name="VEEAM Backup Repository-Agents" dir=in action=allow protocol=tcp localport=10001

Daz braucht man dann nur noch 139/445 für das Deployment und Updates (für ein deutsches Windows 2019/2022). Dazu enablen wir einfach die „default“ Regeln und bauen keine zusätzlichen:

netsh advfirewall firewall set rule name="COM+-Netzwerkzugriff (DCOM-In)" new enable=yes
netsh advfirewall firewall set rule name="Datei- und Druckerfreigabe (SMB eingehend)" new enable=yes

Veeam Backup and Replication Logfile Pfade

Veeam B&R schreibt äußerst großzügige Logfiles, die die Fehlersuche in den allermeisten Fällen wesentlich vereinfachen. Das ist großartige – bitte bitte Veeam, ändert das niemals 😉

Früher(TM) war nicht nur alles besser, sondern man konnte über das Hilfe-Menü den Logfile-Ort schnell und komfortabel aufrufen; doch das war eine sinnvolle und hilfreiche Funktion und musste daher selbstverständlich ersatzlos gestrichen werden.

Naja, nicht ganz ersatzlos, denn dafür gibt es jetzt den freundlichen „Support-Assistenten“, der erst (wortwörtlich) Gigabyteweise Diag-Files zusammenkopiert, diese über alle CPU-Kerne verteilt einpackt und dem Informationensuchenden Admin schon nach einigen Minuten (!) ein wieder neu zu entpackendes .zip mit ALLEN logs darin präsentiert. In vielen Fällen eher sinnfrei, wenn Ihr mich fragt.

Lösung: Für das schnelle debuggen sind die Logfiles hier versteckt:

  • Windows Server XP/2003:
    %allusersprofile%\Application Data\VeeamBackup
  • Windows Server 2008/2008R2/7:
    %allusersprofile%\VeeamBackup
  • Windows Server 2026/2019/2022 und Windows 10: (thx Dezibel)
    %allusersprofile%\Veeam
  • Linux:
    /var/log/VeeamBackup/

Veeam Backup & Replication Console startet nicht (veeam.backup.shell.exe System.Xml.XmlException)

Problem

Die Veeam Backup & Replication Console startet „auf einmal“ nicht mehr. Gestern ging es noch, heute passiert (scheinbar) nichts mehr, es ist nicht einmal der Anmeldedialog zu sehen. Im Ereignisprotokoll sind nach jedem Versuch veeam.backup.shell.exe zu starten diese Fehler zu sehen:

  • Protokoll: Anwendung
  • Quelle: .NET Runtime
  • Ereignis-ID: 1026
Anwendung: veeam.backup.shell.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.Xml.XmlException
bei System.Xml.XmlTextReaderImpl.Throw(System.Exception)
bei System.Xml.XmlTextReaderImpl.ParseText(Int32 ByRef, Int32 ByRef, Int32 ByRef)
bei System.Xml.XmlTextReaderImpl.ParseText()
bei System.Xml.XmlTextReaderImpl.ParseElementContent()

[...]

Lösung

Warscheinlich ist nur die Benutzerkonfiguration der Konsole kaputt. Das .NET Framework ist (ausnahmsweise) da mal nicht schuld.

Es hilft das Löschen der Datei:

%USERPROFILE%\AppData\Local\Veeam_Software_Group_GmbH\veeam.backup.shell.exe_Url_hu1utqnj52thvmhrg5kie2bl15o22i22\10.0.0.0\user.config

Danach startet die Konsole sofort wieder.

Windows Eventlog CAPI2 Event 513 „AddLegacyDriverFiles: Unable to back up image of binary“

Problem

Bei jedem Backup das einen externen VSS-Agenten benutzt, beispielsweise Veeam B&R mit Application Awareness, werden diese Fehler vom Kryptografiedienst (CAPI2 steht für „Windows CryptoAPI v2“) gemeldet. In der Meldung steht „Zugriff zudem verweigert“, was auf fehlenden Zugriffsrechte hindeutet.

Fehler beim Kryptografiedienst während der Verarbeitung des „OnIdentity()“-Aufrufobjekts „System Writer“.

Lösung

Das Dienstobjekt „Microsoft Link-Layer Discovery Protocol“ hat tatsächlich nicht die korrekten Berechtigungen, um vom VSS System Writer gelesen zu werden.

Man kann die Berechtiugung manuell hinzufügen, oder das die Kommandozeile erledigen lassen:

C:\> sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;CCLCSWLOCRRC;;;SU)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)

Danach ist die Meldung sofort verschwunden 🙂

Update: Microsoft hat dazu einen KB-Artikel veröffentlicht https://support.microsoft.com/en-us/help/3209092/event-id-513-when-running-vss-in-windows-server

Veeam Update „Warning 1327.Invalid Drive D:\“

Normalerweise sind Veeam Backup&Replication Updates dank der extensiven Q&A-Kultur von Veeam äußerst stressfrei und unter Berücksichtung der neuen Features/Funktionen schnell erledigt. Es gibt aber ein Problem im Setup der aktuellen Versionen (hier: Update 4a) wenn der „Veeam Backup Catalog“ irgendwann einmal verschoben wurde. Das Update-Setup

Warning 1327.Invalid Drive: D:\

Lösung

Der VBRCatalog wurde offensichtlich irgendwann einmal verschoben. Das Setup liesst bei der Installation einmal den Pfad aus der Windows-Freigabe aus, wenn die Installation lokal ist, und versucht diesen veralteten Pfad dann erfolglos zu nutzen.

  1. In der Computerverwaltung unter den Freigaben die Freigabe „VBRCatalog“ prüfen und den Pfad korrigieren (auf die Berechtigungen achten!)
  2. In der Registry diesen Pfad ebenfalls korrigieren: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Catalog (Zeichenfolge: „CatalogPath“ auf den richtigen Pfad ändern, zum Beispel „C:\VBRCatalog“)

Danach das Setup neu starten und schon läuft es wie gewohnt stressfrei durch.