Veeam hat auf der VeeamON 2024 die v8 des Veeam Backup for M365 angekündigt und ich durfte mich bereits vorab mit der Technical Preview beschäftigen und möchte hier einen ersten Einblick geben.
Umgebung:
Ich habe eine Demoumgebung innerhalb von Microsoft Azure (dedizierter Tentant) aufgebaut und als Quell-Daten einen Microsoft CDX-Tentant mit einer Dauer von 90 Tagen ausgerollt und diesen mit Veeam Backup für M365 verbunden und als Datenbasis verwendet. Die Komponenten sind folgendermaßen bezeichnet:
| Hostname: | Betriebssystem: | Funktion: |
| Lab-Veeam-V365B | Windows Server 2022 Datacenter | Veeam M365 Backup Server |
| Lab-Veeam-V365P1 | Windows Server 2022 Datacenter | Veeam M365 Backup Proxy |
| Lab-Veeam-V365P2 | Windows Server 2022 Datacenter | Veeam M365 Backup Proxy |
| Lab-Veeam-V365P3 | Windows Server 2022 Datacenter | Veeam M365 Backup Proxy |
| Lab-Veeam-V365P4 | Windows Server 2022 Datacenter | Veeam M365 Backup Proxy |
Auf Empfehlung von Veeam habe ich die Systeme über die lokale Hosts-Datei der Systeme gepflegt:
Installation:
Mit Einführung der neuen Version hat Veeam den von VBR bekannten Button „Customize Settings“ in den Installation-Wizard von Veeam für M365 eingeführt. Dort ist u.a. das Service Accounting konfigurierbar:
Man hat nun die Möglichkeit, die Konfiguration der Postgres-Datenbank durchzuführen und Veeam hier vor allem mit einer bereits vorhandenen Installation zu verbinden:
Leider ist das Ganze auf Fehler gelaufen, die folgende Meldungen bringen:
Verwendet habe ich hier den built-in Administrator von Postgres, der im Rahmen der Postgres-Installation angelegt wurde. Auch mit der Standardeinstellung (keine native Anmeldung) gab es eine Fehlermeldung:
Die Installation erfolgte mit Postgres v15.7, da aktuell nur v15-Releases mit Veeam supported sind. Das betrifft sowohl VBR- als auch M365-Installationen.
Die Fehlermeldung wurde an Veeam gemeldet.
Fazit: Um weiter testen zu können, habe ich die Umgebung neu aufgesetzt und Postgres nicht separat vorab installiert. Dies hat fehlerfrei funktioniert und zu keinerlei Fehlermeldungen geführt.
Basiskonfiguration:
Hinzufügen einer M365-Organisation:
Wie oben erwähnt nutze ich einen Microsoft CDX-Tentant als Quelle, um nicht einfach nur leere Accounts zu haben, sondern perspektivisch auch anhand von Beispieldaten testen zu können. Innerhalb von Veeam hat sich der Wizard nicht großartig verändert:
Hinweis: Ich führe hier kein Teams Chat-Backup durch, um Kosten zu sparen. Hier gibt es seit Neuesten seitens Microsoft Gebühren für die erforderlichen API-Call.
Als Authentifizierungsmethode nutze ich Modern Authentication gemäß aktuellen Standards und Best Practices:
Als nächstes folgt wie übliche die App-Registrierung innerhalb von M365, die ich hier automatisch von Veeam durchführen lassen habe:
Ich habe der App einen aussagekräftigen Namen gegeben, um einem Produktivszenario nahe zu kommen:
Abschließend gab es keinerlei weitere Fehler und die Organisation konnte erfolgreich hinzugefügt werden:
Konfiguration von Proxy Servern:
Ich habe in Summe 2 Szenarien, die ich testen möchte:
Szenario 1: Nutzung eines Single-Proxy (hier im Beispiel)
Szenario 2: Nutzung eines Proxy-Pools (neu in v8)
Als Basis nutze ich den o.g. CDX-Tentant und sichere zur Wasabi-Cloud (erst einmal ohne Immutability), die Bedingungen sind für beide Szenarien identisch.
Auf Empfehlung von Veeam habe ich die Proxies mit Hostnamen angesprochen und die einzelnen Server hinzugefügt:
Zur Verbindung habe ich den lokalen Administrator des Zielservers verwendet:
Im Anschluss habe ich eine der neuen Funktionen getestet und die Konfiguration so durchgeführt, dass automatisch ein Service Account (mit entsprechenden Parametern) durch den Wizard auf dem Zielsystem angelegt wird:
Hier bin ich dann auf die ersten Fehler beiden gestoßen:
Es fehlt .NET Runtime und auch PowerShell in der passenden Version. Veeam gibt im Handbuch folgende Voraussetzungen für einen M365 Proxy Server vor:
Nach der Installation der benötigten Komponenten nun ein weiterer Versuch mit folgender Fehlermeldung:
Hier musste ich das erste Mal tiefer einsteigen. Die Veeam Dokumentation gibt die Ports 9191 und 9193 vor, die zwischen dem Veeam M365 Server und dem Proxy Server gesprochen werden. Verbindungen in Richtung Microsoft 365 sind für mich an der Stelle noch nicht relevant.
Ein Blick in das Windows Firewall Log des Proxy Servers ergibt folgendes:
Ein Blick in das Windows Firewall Log des Veeam M365 Servers ergibt folgendes:
Im ersten Screenshot wird der Port 135 des Proxy-Servers angesprochen, dabei handelt es sich um einen RPC-Port. Ich habe den Port eingehen auf dem Proxyserver freigegeben.
Auf dem M365 Server sehen wir, dass der Port 5432 angesprochen wird. Dieser Port wird für den Postgres-Server verwendet. Offenbar versucht der Proxy-Server die DB über diesen Port anzusprechen. Ich habe den Port entsprechend freigegeben.
Neben Port 5432 wird außerdem der Port 4222 angesprochen. Hierbei handelt es sich um den Port, über den der NATS-Server auf dem Veeam M365-Server angesprochen wird. Ich habe auch diesen Port eingehend freigegeben.
Fazit: In der Dokumentation habe ich keinerlei Hinweis auf die o.g. Ports als Voraussetzung gefunden und dies an Veeam (über einen der SE-Kollegen) gemeldet.
Nachdem die entsprechenden Ports in den Windows-Firewall geöffnet wurden, lief die Installation dann fehlerfrei durch:
Hinweis: Die o.g. Warnung bezieht sich auf den Arbeitsspeicher der Proxies. Ich habe hier auf Grund der Verfügbarkeit von Ressourcen das Minimum bewusst leicht unterschritten und dies bei folgenden Tests erhöht.
Automatisch erstellter Service-Account:
Wie oben gezeigt hat Veeam die Erstellung von Service Accounts in den Wizard integriert. Das bedeutet, dass auf dem Zielsystem (hier: Proxy-Server) ein entsprechender Account mit nötigen Rechten erstellt und berechtigt wird. Am Beispiel eines Windows-Servers wird der Account wie folgt erstellt:
Fazit: Folgendes wird automatisch umgesetzt:
- Erstellung des lokalen Windows-Accounts
- Setzten von „Passwort läuft nie ab“
- Hinzufügen zur Gruppe „Performance Monitor Users“
- Gewähren des Rechtes zur Ausführung von Diensten