Mail-Gateway und M365-Backup konsolidieren: Was bei der Ablösung von Cisco und Veeam zu beachten ist

Ein typisches Bild: Vor Exchange Online sitzt seit Jahren ein Cisco Secure Email Gateway, früher als IronPort bekannt. Die Datensicherung für Exchange Online, OneDrive, SharePoint und Teams läuft mit Veeam Backup for Microsoft 365. Beide Produkte funktionieren. Trotzdem soll konsolidiert werden, etwa auf eine Suite wie Hornetsecurity 365 Total Protection, die Filter, Archiv, Verschlüsselung und Backup aus einer Konsole liefert.

Die Gründe sind nachvollziehbar: ein Vertrag, ein Support, eine Oberfläche, oft ein Betriebsdienstleister für alles. Die Risiken liegen nicht im neuen Produkt, sondern im Übergang. Dieser Artikel ist herstellerneutral formuliert. Die Begriffe aus der Cisco- und Veeam-Welt dienen als Beispiel für das, was bei jeder Ablösung zu erfassen ist.

Vorher klären: Was soll die Konsolidierung leisten?

Bevor Sie Regeln exportieren, sollten drei Fragen schriftlich beantwortet sein:

• Funktionsgleichheit oder bewusster Verzicht? Ein Gateway mit über Jahre gewachsenen Content-Filtern bildet Dinge ab, die eine Suite anders oder gar nicht abbildet. Jede Lücke braucht eine Entscheidung: nachbauen, nach Exchange Online verlagern oder entfallen lassen.
• Welche Abhängigkeit entsteht? Filter, Archiv, Verschlüsselung und Backup bei einem Anbieter heißt auch: ein Ausfall oder ein Vertragsende betrifft alles gleichzeitig. Das ist kein Grund gegen Konsolidierung, aber ein Grund für eine saubere Exit-Regelung.
• Wer betreibt was? Wird die Suite als Managed Service betrieben, gehört die Abgrenzung zur internen IT in die Leistungsbeschreibung. Was dort hineingehört, steht im Artikel M365-Security als Managed Service ausschreiben.

Bestandsaufnahme Mail-Gateway

Exportieren Sie zuerst die vollständige Konfiguration. Bei Cisco AsyncOS geht das in der Oberfläche über die Konfigurationsdatei oder per saveconfig auf der Kommandozeile. Diese Datei ist Ihre Referenz für den gesamten Übergang und gehört ins Projektarchiv. Danach gehen Sie die Objekte einzeln durch:

Ergänzend erfassen Sie den Stand in Exchange Online. Wir sichern ihn als JSON, bevor irgendetwas geändert wird. So lässt sich jeder Zustand später vergleichen und notfalls wiederherstellen:

Connect-ExchangeOnline
$ziel = "C:\Bestand\EXO-$(Get-Date -Format yyyyMMdd)"
New-Item -ItemType Directory -Path $ziel -Force | Out-Null
Get-AcceptedDomain                  | ConvertTo-Json -Depth 5 | Out-File "$ziel\accepted-domains.json"
Get-InboundConnector                | ConvertTo-Json -Depth 5 | Out-File "$ziel\inbound-connectors.json"
Get-OutboundConnector               | ConvertTo-Json -Depth 5 | Out-File "$ziel\outbound-connectors.json"
Get-TransportRule                   | ConvertTo-Json -Depth 5 | Out-File "$ziel\transport-rules.json"
Get-JournalRule                     | ConvertTo-Json -Depth 5 | Out-File "$ziel\journal-rules.json"
Get-HostedConnectionFilterPolicy    | ConvertTo-Json -Depth 5 | Out-File "$ziel\connection-filter.json"
Get-HostedContentFilterPolicy       | ConvertTo-Json -Depth 5 | Out-File "$ziel\anti-spam.json"
Get-TenantAllowBlockListItems -ListType Sender | ConvertTo-Json -Depth 5 | Out-File "$ziel\tabl-sender.json"
Get-DkimSigningConfig               | ConvertTo-Json -Depth 5 | Out-File "$ziel\dkim.json"

Whitelists ehrlich prüfen

In jedem gewachsenen Gateway gibt es Zulassungslisten. Sie entstanden aus einem konkreten Anlass, der oft Jahre zurückliegt. Übernehmen Sie sie nicht pauschal. Jeder Eintrag braucht einen Grund und einen fachlichen Ansprechpartner, sonst entfällt er.

• Domain-Zulassungen sind fälschbar. Wer lieferant-beispiel.de pauschal zulässt, lässt auch jede gefälschte Mail mit dieser Absenderdomain durch. Besser: Zulassung an bestandene Authentifizierung koppeln oder auf konkrete Fehlalarme reagieren.
• IP-Zulassungen veralten. Partner wechseln ihren Mailanbieter, die IP gehört dann jemand anderem.
• Exchange Online hat eigene Listen. Einträge in der Verbindungsfilter-Richtlinie, in den Anti-Spam-Richtlinien und in der Tenant Allow/Block List wirken unabhängig vom Gateway. Sie gehören in dieselbe Prüfung.

Bestandsaufnahme M365-Backup

Beim Backup ist die Bestandsaufnahme weniger umfangreich, aber folgenreicher. Erfassen Sie für das Altsystem:

• Umfang: Welche Postfächer, Archive, freigegebenen Postfächer, OneDrives, SharePoint-Sites und Teams werden gesichert? Welche sind bewusst ausgeschlossen?
• Aufbewahrung: Welche Aufbewahrungslogik ist eingestellt, wie lange reichen die Sicherungen zurück, und wo liegt der Speicher? Lokal, im Objektspeicher, mit Unveränderbarkeit?
• Schlüssel: Sind die Sicherungen verschlüsselt? Wo liegen Kennwörter und Schlüssel? Ohne sie ist jede Altsicherung wertlos.
• Zugriffe: Welche App-Registrierung in Entra ID nutzt das Produkt, mit welchen Berechtigungen? Welche Restore-Rollen gibt es?
• Schnittstellen: Nutzt die eingesetzte Version noch Exchange Web Services? Microsoft blockiert EWS in Exchange Online seit dem 1. Oktober 2026 standardmäßig und schaltet es zum 1. April 2027 endgültig ab. Eine alte Version kann deshalb schon vor dem geplanten Ablösetermin aufhören, Postfächer zu sichern.

Altsicherungen: die eigentliche Entscheidung

Ein neues Backup beginnt mit dem Tag der ersten Sicherung. Die Historie des Altsystems lässt sich in der Regel nicht in ein anderes Produkt übernehmen. Lassen Sie sich das vom neuen Anbieter bestätigen, bevor Sie planen. Damit bleibt die Frage, was mit den alten Sicherungen geschieht. Es gibt vier Wege:

In der Praxis ist die Kombination aus befristetem Parallelbetrieb und lesendem Altsystem am häufigsten. Wichtig ist, die Entscheidung mit Datum und Verantwortlichem zu dokumentieren. Ein Backup ist kein Archiv: Für Aufbewahrungspflichten von sechs oder zehn Jahren ist das E-Mail-Archiv zuständig, nicht die Datensicherung. Worauf es dort ankommt, beschreibt der Artikel E-Mail-Archivierung auswählen.

Lizenzlaufzeiten und Parallelbetrieb

Lizenzen und Wartungsverträge der Altprodukte laufen selten zum selben Datum aus. Legen Sie die Termine nebeneinander und planen Sie rückwärts:

• Kündigungsfristen der Altverträge und deren automatische Verlängerung
• Startdatum der neuen Lizenzen. Werden sie vom Auftraggeber beigestellt, gehört das Datum der Bereitstellung in den Projektplan, nicht nur in den Vertrag.
• Lizenzumfang. Passen Plan und Menge zum Bedarf? Bei Hornetsecurity 365 Total Protection etwa enthält erst Plan 3 das Backup, Plan 1 deckt Filter, Verschlüsselung und Signaturen ab. Freigegebene Postfächer, Ressourcenpostfächer und Archive zählen je nach Produkt unterschiedlich.
• Überlappung. Rechnen Sie mindestens die Übergangszeit der MX-Umstellung und die Zeit bis zur ersten vollständigen Sicherung aller Objekte mit Wiederherstellungstest ein.

Beim Gateway ist echter Parallelbetrieb pro Domain nicht möglich, weil es nur einen MX gibt. Möglich ist eine gestaffelte Umstellung Domain für Domain und eine Übergangszeit, in der das alte Gateway weiter annimmt. Wie das ohne Mailverlust gelingt, steht im Artikel Mail-Gateway vor Exchange Online. Beim Backup ist Parallelbetrieb einfach, aber nicht kostenlos: Beide Produkte lesen über die Microsoft-Schnittstellen, und Microsoft drosselt bei hoher Last. Verteilen Sie die Sicherungsfenster, besonders während der ersten Vollsicherung des neuen Systems.

Abnahme: was „fertig“ bedeutet

Eine Abnahme mit „Mails kommen an“ reicht nicht. Definieren Sie die Kriterien vor dem Projektstart:

Rückbau: der Teil, der gern liegen bleibt

Nach der Abnahme beginnt die Phase, die in Projektplänen oft fehlt. Altlasten sind nicht harmlos: Ein vergessener Connector öffnet einen zweiten Weg in den Tenant, eine vergessene App-Registrierung behält Lesezugriff auf alle Postfächer.

• IP-Adressen des alten Gateways aus Partner-Connector, Enhanced Filtering und Verbindungsfilter entfernen
• Alte Inbound und Outbound Connectors löschen, SCL-1-Regeln für das alte Gateway entfernen
• SPF-Include und DKIM-Selektoren des alten Gateways aus dem DNS nehmen, sobald keine Mails mehr darüber laufen
• Firewall-Freigaben, Monitoring-Checks und alte MX-Hostnamen bereinigen
• App-Registrierung und Dienstkonten des alten Backups entfernen, sobald die Entscheidung zu den Altsicherungen umgesetzt ist
• Restore-Rollen und administrative Zugänge des Altsystems entziehen
• Verträge kündigen, Hardware und Speicher nach Datenschutzvorgaben löschen und entsorgen

# App-Registrierungen des alten Backups finden (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -All | Where-Object DisplayName -like "*Veeam*" |
  Select-Object DisplayName, AppId, Id
# Nach Prüfung und Freigabe entfernen
# Remove-MgServicePrincipal -ServicePrincipalId "<Id>"

Der Löschbefehl ist bewusst auskommentiert. Prüfen Sie vorher, dass kein anderes System dieselbe Registrierung nutzt, und dokumentieren Sie den Schritt.

Fazit

Die Ablösung von Gateway und Backup ist kein Produktwechsel, sondern ein kleines Migrationsprojekt mit Bestandsaufnahme, Übergang, Abnahme und Rückbau. Die Technik ist dabei selten das Problem. Entscheidend ist, dass alte Regeln bewusst übernommen oder verworfen werden, die Altsicherungen eine dokumentierte Zukunft haben und am Ende nichts im Tenant zurückbleibt, das niemand mehr betreut. Wie wir solche Übergänge begleiten und danach betreiben, beschreibt unsere Seite zum M365-Security Managed Service. Für die Datensicherung selbst siehe M365-Backup.

Nils Lappenbusch

Microsoft Certified Trainer · Exchange- und M365-Experte

Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.

Kontakt aufnehmen