
E-Mail-Archivierung ist eines dieser Themen, die viele Unternehmen erst dann ernst nehmen, wenn es eigentlich schon zu spät ist: Betriebsprüfung, Streitfall, ausgeschiedene Mitarbeitende, gelöschte Postfächer oder eine Migration, bei der plötzlich alte Kommunikation fehlt.
Gerade bei Microsoft 365 entsteht schnell der Eindruck: „Unsere Mails liegen doch in der Cloud, also ist alles sicher.“ Technisch stimmt das nur teilweise. Microsoft 365 ist primär ein produktives Mail- und Collaboration-System. Eine sauber konfigurierte Archivierung muss zusätzlich dafür sorgen, dass ein- und ausgehende E-Mails nachvollziehbar, vollständig und manipulationsgeschützt archiviert werden.
In diesem Artikel zeigen wir, wie wir eine Microsoft-365-Full-Cloud-Umgebung mit MailStore Server und MailStore Gateway aufgebaut haben. Ohne Hybrid Exchange, ohne MX-Umzug der produktiven Maildomain und ohne öffentliche Freigabe der MailStore-Oberfläche.
Ziel des Setups
Das Setup in diesem Artikel:
Microsoft 365 / Exchange Online
|
| Journal Reports
v
MailStore Gateway
MailStore Gateway
^
|
| Abruf/Archivierung durch MailStore Server
v
MailStore Server Archiv
Microsoft 365 / Exchange Online
^
|
| Abruf/Archivierung durch MailStore Server
v
MailStore Server Archiv
Die normale Mailzustellung bleibt vollständig bei Microsoft 365. Der MX-Flow der produktiven Domain wird nicht umgebaut. MailStore Gateway dient nur als externer Empfänger für Journalberichte.
Das ist wichtig: Journaling ist keine Weiterleitung und kein Ersatz für den normalen Mailflow. Exchange Online erzeugt bei passenden Nachrichten zusätzliche Journal Reports. Diese enthalten die Originalnachricht als Anhang und werden an ein externes Archivziel zugestellt. Microsoft beschreibt Journaling als ältere Exchange-Funktion, die Daten außerhalb von Microsoft 365 ablegt; für Drittanbieter-Archivierung ist genau dieses Szenario weiterhin relevant.
Voraussetzungen
Für dieses Setup verwenden wir:
Windows Server Standard 2025
MailStore Server
MailStore Gateway
Microsoft 365 / Exchange Online
eine eigene Gateway-Subdomain, z. B. monkey.banana.com
VPN/interner Zugriff auf die MailStore-Oberflächen
MailStore Server kann laut MailStore grundsätzlich auf Windows installiert werden und auch in einer virtuellen Maschine betrieben werden. Für produktive Umgebungen sollte das System trotzdem sauber getrennt, überwacht und gesichert werden.
Wir empfehlen außerdem eine klare Trennung von System- und Archivdaten:
C:\ Windows + Programme
D:\Gateway MailStore Gateway Daten
D:\Archive MailStore Server Archivdaten
Der Grund ist simpel: Archive wachsen. Wenn die Systempartition vollläuft, ist nicht nur MailStore betroffen, sondern der ganze Windows Server.
DNS und Firewall vorbereiten
Für das Gateway nutzen wir eine eigene Subdomain, zum Beispiel:
monkey.banana.com
DNS:
monkey.banana.com. A <öffentliche IP des Windows Servers>
monkey.banana.com. MX 10 monkey.banana.com.
Wichtig: Der MX der produktiven Domain, z. B. banana.com, bleibt unverändert bei Microsoft 365. Nur die Gateway-Subdomain bekommt einen eigenen MX-Eintrag.
Öffentlich freigegeben werden nur die Ports, die wirklich benötigt werden:
TCP 25 SMTP zum MailStore Gateway
TCP 80 Let's Encrypt HTTP-01 Challenge
MailStore Gateway dokumentiert Port 25 für die Zustellung an Gateway-Postfächer und Port 80 für die Let’s-Encrypt-Challenge. Der Management-Port 8450 ist für Administratoren gedacht und sollte nicht öffentlich für das Internet geöffnet werden.
In unserem Setup liegt der Windows Server im internen Netz und ist über VPN erreichbar. Deshalb bleiben diese Ports intern:
TCP 8450 MailStore Gateway Management Console
TCP 8460 MailStore Client
TCP 8462 MailStore Web Access / Outlook Add-in
TCP 8463 MailStore Management API
RDP nur intern/VPN, nicht öffentlich
Falls MailStore Server selbst ein Let’s-Encrypt-Zertifikat beziehen soll, muss ebenfalls ein öffentlicher DNS-Eintrag auf den Server zeigen und TCP 80 erreichbar sein.
MailStore Gateway installieren und konfigurieren
Zuerst wird MailStore Gateway installiert. Im Konfigurationswerkzeug setzen wir:
E-Mail-Domäne: monkey.banana.com
Management Console Port: 8450
Let's Encrypt Port: 80
Zertifikat: Let's Encrypt für monkey.banana.com
RFC 3030-Unterstützung: aktiviert
Die E-Mail-Domäne ist der Domainteil der späteren Gateway-Mailboxen. Aus einer Gateway-Mailbox wird dann zum Beispiel:
mbx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@monkey.banana.com
MailStore beschreibt im Gateway-Konfigurationswerkzeug, dass die konfigurierte E-Mail-Domäne per DNS auflösbar sein muss und für diese Gateway-Domain ein MX-Eintrag auf den A-Record zeigen sollte.

Nach erfolgreicher Zertifikatsanforderung wird der Gateway-Dienst gestartet.
Prüfen auf dem Windows Server:
Get-Service MailStoreGateway
netstat -ano | findstr ":25"
netstat -ano | findstr ":8450"
Erwartung:
MailStoreGateway Running
0.0.0.0:25 LISTENING
0.0.0.0:8450 LISTENING
Gateway Admin-Zugang und Passwort-Reset
Die Gateway Management Console ist erreichbar unter:
https://monkey.banana.com:8450
oder intern/VPN:
https://<interne-ip>:8450
Der Benutzer ist:
admin
Falls das Admin-Passwort nicht bekannt ist, kann es über den offiziellen Locksmith-Befehl zurückgesetzt werden. MailStore dokumentiert dafür diesen Ablauf: Gateway-Dienst stoppen, in den Service-Ordner wechseln, Host.exe /locksmith ausführen und anschließend den Dienst wieder starten.
Stop-Service MailStoreGateway
cd "C:\Program Files\MailStore\MailStore Gateway\service"
.\Host.exe /locksmith
Start-Service MailStoreGateway

Gateway-Daten auf die Datenplatte verschieben
Standardmäßig liegen Gateway-Daten unter:
C:\ProgramData\MailStore\Gateway
Für produktive Setups legen wir diese Daten auf die Datenplatte, z. B.:
D:\Gateway
MailStore dokumentiert für das Verschieben des Gateway-Mailbox-Ordners einen Symlink-/Junction-Ansatz. Genau diesen Weg nutzen wir.
PowerShell/CMD als Administrator:
Stop-Service MailStoreGateway
Dann:
mkdir D:\Gateway
robocopy "C:\ProgramData\MailStore\Gateway" "D:\Gateway" /MIR /COPYALL /XJ
ren "C:\ProgramData\MailStore\Gateway" Gateway.old
cd "C:\ProgramData\MailStore"
cmd /c mklink /D Gateway D:\Gateway
Gateway wieder starten:
Start-Service MailStoreGateway
Get-Service MailStoreGateway
Prüfen:
dir "C:\ProgramData\MailStore"
dir "D:\Gateway"
Im C:\ProgramData\MailStore-Ordner sollte nun ein Link Gateway auf D:\Gateway zeigen.
Den alten Ordner Gateway.old nicht sofort löschen. Erst nach Neustart und Funktionstest entfernen.
Gateway-Postfach für Journaling anlegen
In der Gateway Management Console wird jetzt ein neues Postfach angelegt, z. B.:
Name: Journal
MailStore Gateway erzeugt daraus eine technische Mailbox-ID, zum Beispiel:
mbx-99zYY6O901WaTfF5MAO6D3iNmzy3KdQg
Die daraus resultierende SMTP-Adresse lautet dann:
mbx-99zYY6O901WaTfF5MAO6D3iNmzy3KdQg@monkey.banana.com
Diese Adresse wird später in Microsoft Purview / Exchange Online als Ziel für Journal Reports hinterlegt.
Wichtig: Das Passwort des Gateway-Postfachs direkt sicher speichern. Es wird später im MailStore Server benötigt, damit dieser die Journal Reports aus dem Gateway-Postfach abrufen kann.

Jetzt eine direkte Testmail an die Gateway-Adresse senden:
mbx-99zYY6O901WaTfF5MAO6D3iNmzy3KdQg@monkey.banana.com
Wenn die Nachrichtenzahl im Gateway steigt, funktionieren DNS, SMTP-Port 25 und Gateway-Zustellung grundsätzlich.
Was Journaling eigentlich macht
Journaling sorgt dafür, dass Exchange Online beim Senden oder Empfangen einer E-Mail eine zusätzliche Kopie erzeugt. Diese Kopie wird als Journal Report an ein spezielles Journalziel geschickt. Der Journal Report enthält Metadaten wie Absender, Empfänger und Message-ID; die Originalmail liegt unverändert als Anhang bei.
MailStore nutzt diese Journal Reports, wertet die tatsächlichen Absender und Empfänger aus und ordnet die Mails anschließend den jeweiligen Benutzerarchiven zu. MailStore weist darauf hin, dass nur über die Journaling-Funktionalität ein- und ausgehende E-Mails aller Postfächer automatisch und vollständig archiviert werden können.
Kurz gesagt:
Normale Mail:
Absender → Microsoft 365 → Empfänger
Journal-Kopie:
Microsoft 365 → MailStore Gateway → MailStore Server Archiv
Microsoft 365: Externes Journalziel vorbereiten
Bevor die Journalregel erstellt wird, empfiehlt MailStore, für das externe Gateway-Ziel einen externen Kontakt in Exchange anzulegen. Das vermeidet Warnungen oder Probleme mit unbekannten externen Empfängern.
In Microsoft 365 / Exchange Admin Center:
Empfänger
→ Kontakte
→ E-Mail-Kontakt hinzufügen
Beispiel:
Anzeigename: MailStore Journal Gateway
Externe E-Mail-Adresse:
mbx-99zYY6O901WaTfF5MAO6D3iNmzy3KdQg@monkey.banana.com
Danach kann dieser Kontakt als Ziel für Journalberichte verwendet werden.
Unzustellbare Journalberichte: nicht ignorieren
Microsoft und MailStore weisen beide darauf hin, dass Journalberichte sensible Informationen enthalten und dass das Journalziel überwacht werden muss. Wenn das Journalziel nicht erreichbar ist, versucht Exchange Online die Zustellung bis zu 24 Stunden erneut. Danach wird ein Non-Delivery Report an die Alternate Journaling Mailbox gesendet.
Wichtig: Eine Exchange-Online-Mailbox darf laut Microsoft nicht als Journaling Mailbox oder Alternate Journaling Mailbox verwendet werden. Auch MailStore schreibt, dass dieses Postfach für unzustellbare Journalberichte nicht innerhalb eines Microsoft-365-Mandanten liegen darf.
In Purview wird deshalb zuerst gesetzt:
Unzustellbare Journalberichte senden an:
<externes NDR-/Fallback-Postfach>
Dieses Postfach sollte überwacht werden. Wenn dort NDRs eingehen, ist das ein echtes Compliance-Problem und kein kosmetischer Fehler.
Journalregel in Microsoft Purview erstellen
Direktlink:
https://purview.microsoft.com/datalifecyclemanagement/exchange/journalrules
Dort:
Datenlebenszyklusverwaltung
→ Exchange (Legacy)
→ Journalregeln
Neue Journalregel:
Journalberichte senden an:
MailStore Journal Gateway
bzw. mbx-...@monkey.banana.com
Name:
MailStore Journaling All
Journalnachrichten gesendet oder empfangen von:
[Auf alle Nachrichten anwenden]
Typ der Nachricht:
Alle Nachrichten
Status:
Ein
Microsoft unterscheidet beim Journaling zwischen dem Scope der Regel, dem Journal Recipient und der Journaling Mailbox. Wenn kein einzelner Journal Recipient eingeschränkt wird, greifen die Regeln für alle Nachrichten, die zum Scope passen. Bei „Alle Nachrichten“ betrifft das interne und externe Nachrichten, die durch die Exchange-Organisation laufen.

Nach dem Speichern nicht sofort nervös werden. Änderungen können etwas Zeit brauchen. Zusätzlich gilt: Wenn das Journalziel nicht erreichbar ist, landen Reports zunächst in Microsofts Transport Queue und werden für einen Zeitraum erneut zugestellt.
Test:
extern → user@banana.com
user@banana.com → extern
user1@banana.com → user2@banana.com
Danach im Gateway prüfen, ob die Nachrichtenanzahl steigt.
MailStore Server installieren
Anschließend wird MailStore Server installiert. MailStore beschreibt die Installation als normales Windows-Installationsprogramm. Beim Setup werden Lizenz, Zertifikat und Grundkonfiguration eingerichtet. Für Let’s Encrypt braucht auch MailStore Server einen auflösbaren DNS-Namen und Erreichbarkeit auf TCP 80, wenn das Zertifikat direkt über MailStore bezogen werden soll.
Für unser Setup liegt die MailStore-Oberfläche nicht öffentlich im Internet. Zugriff erfolgt intern oder per VPN.
Standardports:
8460 MailStore Client
8462 MailStore Web Access / Outlook Add-in
8463 Management API
Diese Ports müssen nicht öffentlich erreichbar sein, wenn Benutzer und Administratoren per VPN oder intern zugreifen.
Archivdaten auf D:\Archive legen
MailStore Server sollte nicht dauerhaft auf C:\ archivieren. Bei einer frischen Installation setzen wir den Archivpfad direkt auf:
D:\Archive
Falls bereits ein frisches Archiv unter C:\MailArchive angelegt wurde, kann es vor dem Produktivbetrieb verschoben werden:
Stop-Service MailStoreServer
mkdir D:\Archive
robocopy "C:\MailArchive" "D:\Archive" /MIR /COPYALL /XJ
Danach in der MailStore Server Dienst-Konfiguration den Pfad der Master-Datenbank bzw. des Archivs auf D:\Archive setzen und den Dienst wieder starten:
Start-Service MailStoreServer
Get-Service MailStoreServer
MailStore dokumentiert das Verschieben des Archivs über die Storage-/Archiv-Konfiguration. Für das Hauptarchiv ist das sauberer als ein blinder Symlink.
MailStore Server mit Microsoft 365 verbinden
Damit MailStore Journal Reports den richtigen Benutzerarchiven zuordnen kann, müssen die Benutzer und ihre E-Mail-Adressen in MailStore bekannt sein.
Das geht manuell, sauberer ist aber die Synchronisierung mit Microsoft 365 / Entra ID.
In MailStore:
Verwaltung
→ Benutzer und Archive
→ Verzeichnisdienste
→ Microsoft 365
MailStore beschreibt, dass bei der Synchronisierung Benutzernamen und E-Mail-Adressen aus dem Microsoft-365-Mandanten in die MailStore-Benutzerdatenbank kopiert werden. Dabei werden keine Änderungen am Microsoft-365-Mandanten vorgenommen.
Für die Verbindung wird eine App Registration in Entra ID erstellt:
Microsoft Entra Admin Center
→ App registrations
→ New registration
Danach werden in MailStore eingetragen:
Anwendungs-ID (Client)
Verzeichnis-ID (Mandant)
Zertifikat aus MailStore

Das von MailStore erzeugte Zertifikat wird anschließend in Entra ID unter:
Certificates & secrets
→ Certificates
→ Upload certificate
hochgeladen.
Für die Redirect URI nutzt MailStore das Format:
https://<fqdn>[:<port>]/oidc/signin
Beispiel:
https://monkey.banana.com:8462/oidc/signin
Der Pfad /oidc/signin muss exakt stimmen, und die URI ist case-sensitive. Außerdem muss in Entra ID die Option ID tokens aktiviert werden.

API-Berechtigungen in Entra ID
Für die App Registration müssen die benötigten API-Berechtigungen gesetzt und per Admin Consent bestätigt werden.
MailStore nennt für aktuelle Versionen unter Microsoft Graph:
Directory.Read.All
Mail.ReadWrite
und unter „Office 365 Exchange Online“:
full_access_as_app
SMTP.SendAsApp
IMAP.AccessAsApp
Danach muss die Administratorzustimmung für den Tenant erteilt werden.

Wichtig: Diese Berechtigungen sind weitreichend. MailStore weist darauf hin, dass MailStore Server als Windows-Dienst mit Application Permissions arbeitet und dadurch Zugriff auf Postfächer im Mandanten erhält. Deshalb sollten Zugriff auf Archivierungsprofile und Administration auf MailStore-Administratoren beschränkt werden.
MailStore Archivierungsprofil für Gateway erstellen
Jetzt wird MailStore Server so eingerichtet, dass er das Gateway-Postfach regelmäßig abholt.
In MailStore Client:
E-Mails archivieren
→ E-Mail-Server
→ Microsoft 365
→ E-Mails sofort bei Ein- und Ausgang
MailStore beschreibt diesen Weg explizit für die Archivierung über MailStore Gateway und Microsoft 365 Journaling. Im Assistenten werden Servername, Postfach-ID und Kennwort des Gateway-Postfachs eingetragen.
Beispiel:
Servername: monkey.banana.com
Postfach-ID: mbx-99zYY6O901WaTfF5MAO6D3iNmzy3KdQg
Kennwort: <Gateway-Mailbox-Passwort>
Wenn das Gateway-Zertifikat vom MailStore-Server nicht als vertrauenswürdig erkannt wird, kann für den Test „Alle Zertifikate akzeptieren“ aktiviert werden. Produktiv sollte das Zertifikat sauber vertrauenswürdig sein.
Beim Zeitplan empfehlen wir kurze Intervalle:
alle 5 bis 15 Minuten
Das Gateway ist nur ein Puffer. Es sollte nicht tagelang anwachsen, nur weil MailStore selten abholt.


Löschverhalten im Gateway
MailStore bietet im Archivierungsprofil die Option, wann archivierte E-Mails aus dem Gateway-Postfach gelöscht werden sollen. Das sollte zur Backup-Strategie passen. MailStore nennt als Beispiel, die Löschung um einen Tag zu verzögern, wenn täglich gesichert wird.
Pragmatische Einstellung:
Archivierte Gateway-Mails erst nach erfolgreichem Backup löschen
So vermeidet man, dass eine Mail zwar aus dem Gateway gelöscht wurde, aber noch nicht in einem gesicherten Archivbestand enthalten ist.
Dienste automatisch und zuverlässig starten
Nach einem Reboot sollen MailStore Server und Gateway ohne Admin-Login starten. Beide laufen als Windows-Dienste.
PowerShell als Administrator:
Set-Service MailStoreGateway -StartupType Automatic
sc.exe config MailStoreGateway start= delayed-auto
sc.exe failure MailStoreGateway reset= 86400 actions= restart/60000/restart/60000/restart/60000
Set-Service MailStoreServer -StartupType Automatic
sc.exe config MailStoreServer start= delayed-auto
sc.exe failure MailStoreServer reset= 86400 actions= restart/60000/restart/60000/restart/60000
Falls Dienste beim Boot zu früh starten, hilft zusätzlich ein höherer ServicesPipeTimeout:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control" `
-Name "ServicesPipeTimeout" `
-Value 120000 `
-PropertyType DWORD `
-Force
Danach den Server neu starten und prüfen:
Get-Service MailStoreServer,MailStoreGateway
netstat -ano | findstr ":25"
netstat -ano | findstr ":8450"
netstat -ano | findstr ":8460"
netstat -ano | findstr ":8462"
Test und Kontrolle
Nach vollständiger Einrichtung testen wir in drei Richtungen:
1. Extern → Microsoft-365-Postfach
2. Microsoft-365-Postfach → extern
3. Microsoft-365-Postfach → Microsoft-365-Postfach
Danach prüfen:
MailStore Gateway:
Nachrichtenanzahl steigt?
MailStore Server:
Archivierungsprofil läuft erfolgreich?
MailStore Suche:
Testmail im richtigen Benutzerarchiv auffindbar?
Wenn die direkte Testmail an das Gateway funktioniert, aber keine Journal Reports eintreffen, liegt das Problem meist nicht am Gateway, sondern an der Journalregel, dem externen Kontakt, der Purview-Konfiguration oder der Zustellung aus Exchange Online.
Hilfreich ist dann die Nachrichtenablaufverfolgung in Exchange Online:
Exchange Admin Center
→ E-Mail-Fluss
→ Nachrichtenablaufverfolgung
→ Empfänger: mbx-...@monkey.banana.com
Hinweis: Dieser Artikel ist eine technische Anleitung und keine Rechtsberatung. Anforderungen können je nach Unternehmen, Branche und internen Aufbewahrungspflichten unterschiedlich sein. Handeln auf eigene Gefahr.
Typische Fehler
Port 25 offen, aber Let’s Encrypt schlägt fehl
Let’s Encrypt prüft nicht Port 25, sondern Port 80. Für HTTP-01 muss http://monkey.banana.com/.well-known/acme-challenge/... von außen erreichbar sein. MailStore Gateway nutzt Port 80 temporär für die Challenge.
Gateway-Adresse direkt erreichbar, aber Journaling kommt nicht an
Eine direkte Testmail an die Gateway-Adresse prüft nur SMTP/DNS. Sie beweist nicht, dass Exchange Online Journal Reports erzeugt. Dafür muss die Journalregel greifen und die Nachrichtenablaufverfolgung Einträge an die Gateway-Adresse zeigen.
Falsches Journalziel
In der Journalregel muss die echte SMTP-Adresse des Gateway-Postfachs stehen, also zum Beispiel:
mbx-99zYY6O901WaTfF5MAO6D3iNmzy3KdQg@monkey.banana.com
Nicht nur der Anzeigename „Journal“.
Alternate Journaling Mailbox falsch gewählt
Eine Exchange-Online-Mailbox ist laut Microsoft als Journaling Mailbox und Alternate Journaling Mailbox nicht unterstützt. Das Fallback-Ziel muss sauber extern sein und überwacht werden.
Benutzer werden in MailStore nicht zugeordnet
Dann fehlen meist E-Mail-Adressen oder Aliase in den MailStore-Benutzern. MailStore weist ausdrücklich darauf hin, dass die E-Mail-Adressen in den Benutzereigenschaften gepflegt sein müssen, damit Mails korrekt zugeordnet werden können.
Zusätzlich sollte regelmäßig getestet werden, ob ein Restore wirklich funktioniert. Gerade bei rechtlich relevanten Daten ist ein Backup ohne Restore-Test nur ein gutes Gefühl, aber kein belastbares Konzept.
Backup nicht vergessen
Ein Mailarchiv ohne Backup ist kein Archiv, sondern eine Wette.
Mindestens sichern:
D:\Archive
D:\Gateway
MailStore Konfiguration
Lizenzdaten
Recovery Key
Admin-Zugangsdaten
Dokumentation der Journalregel
Fazit
Mit Microsoft 365, MailStore Server und MailStore Gateway lässt sich eine saubere, nachvollziehbare E-Mail-Archivierung aufbauen, ohne den produktiven MX-Flow umzubauen.
Der entscheidende Punkt ist die Architektur:
Microsoft 365 bleibt produktiver Mailserver.
MailStore Gateway nimmt nur Journal Reports entgegen.
MailStore Server archiviert und ordnet die Mails den Benutzern zu.
Damit das Setup belastbar wird, müssen aber Details stimmen: DNS, Port 25, Port 80 für Zertifikate, externe Journaladresse, korrektes Fallback für unzustellbare Journalberichte, Benutzer-Synchronisierung, Archivpfade, Dienststart und Backup.
Genau an diesen Stellen passieren in der Praxis die meisten Fehler. Und genau deshalb lohnt es sich, das Thema nicht „mal schnell nebenbei“ zu machen.
Wir unterstützen Unternehmen bei Planung, Einrichtung und Betrieb von Microsoft-365-Mailarchivierung mit MailStore – inklusive sauberer Dokumentation, Firewall-Konzept, Backup-Strategie und Monitoring.
Quick Checklist
[ ] Windows Server vorbereitet
[ ] Datenplatte für Gateway und Archiv vorhanden
[ ] DNS A-Record für monkey.banana.com gesetzt
[ ] MX für monkey.banana.com gesetzt
[ ] TCP 25 öffentlich zum Gateway
[ ] TCP 80 öffentlich für Let's Encrypt
[ ] Gateway installiert und Zertifikat eingerichtet
[ ] Gateway-Postfach angelegt
[ ] Testmail ans Gateway erfolgreich
[ ] Externer Kontakt in Exchange angelegt
[ ] Alternate Journaling Mailbox extern gesetzt
[ ] Journalregel in Purview erstellt
[ ] MailStore Server installiert
[ ] Archivpfad auf Datenplatte gesetzt
[ ] Microsoft-365-Sync / Entra App eingerichtet
[ ] API Permissions + Admin Consent erteilt
[ ] Archivierungsprofil für Gateway angelegt
[ ] Zeitplan aktiviert
[ ] Backup eingerichtet
[ ] Restore-Test geplant
Quellen
- Microsoft Learn: Journaling in Exchange Online — https://learn.microsoft.com/en-us/exchange/security-and-compliance/journaling/journaling
- Microsoft Purview: Journal rules — https://purview.microsoft.com/datalifecyclemanagement/exchange/journalrules
- MailStore Help: Installation — https://help.mailstore.com/de/server/Installation
- MailStore Help: E-Mail-Archivierung von Microsoft 365 – Modern Authentication — https://help.mailstore.com/de/server/E-Mail-Archivierung_von_Microsoft_365_-_Modern_Authentication
- MailStore Help: Synchronisieren von Benutzerkonten mit Microsoft 365 – Modern Authentication — https://help.mailstore.com/de/server/Synchronisieren_von_Benutzerkonten_mit_Microsoft_365_-_Modern_Authentication
- MailStore Help: Gateway Firewall-Konfiguration — https://help.mailstore.com/de/gateway/Firewall-Konfiguration
- MailStore Help: Gateway Administratorkennwort zurücksetzen — https://help.mailstore.com/de/gateway/Administratorkennwort_zurücksetzen