Outlook unter Windows 11: IMAP- und Exchange-Synchronisation prüfen, wenn Mails fehlen, doppelt sind oder verspätet eintreffen

Technische Abgrenzung: IMAP vs. Exchange Online, OST/PST-Cache und typische Fehlerbilder (Fehlen, Duplikate, Verzögerung)

Synchronisationsprobleme unter Windows 11 lassen sich nur sauber einordnen, wenn Protokoll, Servertyp und lokales Cache-Verhalten getrennt betrachtet werden. IMAP synchronisiert primär Ordnerinhalte (Header und Nachrichtenkörper) über ein generisches Standardprotokoll; Exchange Online arbeitet in Outlook üblicherweise über MAPI/HTTP mit serverseitigen Zuständen für Ordner, Kategorien, Lesestatus, Regeln und viele Metadaten. Zusätzlich entscheidet der lokale Cache (OST/PST), ob ein Problem tatsächlich „auf dem Server“ existiert oder nur in der lokalen Darstellung entsteht.

IMAP: Standardprotokoll mit Grenzen bei Zuständen und Sonderfällen

Bei IMAP ist der Server die Referenz für Ordnerstruktur und Nachrichtenbestand, während der Client je nach Implementierung nicht jeden Zustand identisch abbildet. Flags wie „Gelesen“ oder „Markiert“ werden synchronisiert, komplexere Outlook-Konzepte (z. B. Kategorien, Nachverfolgungskennzeichen, serverseitige Suchordner) sind jedoch nicht Teil des IMAP-Standards. In der Praxis führt das zu scheinbar „fehlenden“ Mails, wenn Clients unterschiedliche Ordnerabonnements nutzen, oder zu „Duplikaten“, wenn eine Nachricht durch Kopier-/Verschiebeoperationen und parallel aktive Clients mehrfach in Zielordnern landet.

Ein weiterer IMAP-Sonderfall ist die Zuordnung von „Gesendet“, „Papierkorb“ und „Entwürfe“. Viele Server erwarten bestimmte Ordnernamen oder spezielle IMAP-Attribute; Clients treffen teils eigene Heuristiken. Wird „Gesendet“ gleichzeitig lokal gespeichert und zusätzlich vom Server in einen anderen Ordner abgelegt, entstehen doppelte Einträge. Bei Verzögerungen dominieren außerdem serverseitige Indizierung, Quotas und aggressive Verbindungs-Timeouts (besonders bei Mobilnetzen) – alles Faktoren, die Outlook nicht immer als eindeutige Fehlermeldung darstellt.

Exchange Online in Outlook: MAPI/HTTP, serverseitige Zustände, andere Fehlerlogik

Exchange Online (Microsoft 365) liefert in Outlook eine deutlich reichere Synchronisationslogik. Ordnerhierarchie, Berechtigungen, Delegationen, freigegebene Postfächer, Archivpostfächer und die serverseitige Volltextsuche greifen ineinander. Outlook nutzt typischerweise den Cached Exchange Mode und hält eine OST als Offlineabbild. Damit wird die lokale Anzeige stark von der Konsistenz zwischen OST und Serverzustand bestimmt: Eine Mail kann serverseitig vorhanden sein, in Outlook aber fehlen, weil die OST einen inkonsistenten Index oder einen hängen gebliebenen Downloadzustand besitzt. Umgekehrt können „Duplikate“ entstehen, wenn Elemente kurzfristig sowohl im lokalen Cache als auch nach erneuter Serverauflösung dargestellt werden (z. B. nach Abbrüchen, Add-in-bedingten Resets oder beim Wechsel zwischen Online-/Cache-Ansicht).

Exchange-spezifische Verzögerungen zeigen sich häufig als „Neue Mail ist in OWA sichtbar, aber Outlook zieht nicht nach“. Ursache ist dann nicht das SMTP-„Ankommen“, sondern die Client-Synchronisation (MAPI/HTTP) oder ein lokaler Cachekonflikt. In diese Kategorie fallen auch Probleme rund um „Download nur Kopfzeilen“ (typischer bei POP/IMAP; bei Exchange eher bei sehr großen Nachrichten/Anhängen bzw. bei nicht vollständig heruntergeladenen Elementen), lokale Suchindizes sowie der Umgang mit großen Postfächern und vielen freigegebenen Ordnern, die den Synchronisationsumfang in der OST erhöhen.

OST vs. PST: Was lokal gespeichert wird und warum das die Diagnose prägt

Eine OST ist eine Cache-Datei für Exchange- bzw. Outlook.com-Konten (und in bestimmten Konstellationen auch für IMAP), die als Spiegel des Serverzustands dient und bei Bedarf neu aufgebaut werden kann. Eine PST ist dagegen eine eigenständige Datendatei (lokales Archiv, POP-Download, manuell angebundene Datei) und damit keine „Synchronisationskopie“ im selben Sinn. Werden Elemente in eine PST verschoben, sind sie aus der serverbasierten Synchronisationskette herausgelöst; „fehlende“ E-Mails sind dann oft schlicht lokal abgelegt oder durch Regeln/AutoArchivierung verschoben worden.

Unter Windows 11 tritt zusätzlich der Effekt auf, dass Identitätswechsel (z. B. erneute Anmeldung, Token-Probleme, Profilwechsel) nicht die Datei selbst beschädigen müssen, aber den Zugriffspfad oder die Zuordnung im Outlook-Profil ändern können. Die Dateipfade sind für die Forensik relevant, weil sie zeigen, ob Outlook überhaupt gegen die erwartete OST/PST arbeitet.

• Typische OST-Ablage (Click-to-Run): %LOCALAPPDATA%\Microsoft\Outlook\
• Typische PST-Ablage (variabel, häufig): %USERPROFILE%\Documents\Outlook-Dateien\ bzw. %USERPROFILE%\Documents\Outlook Files\ (abhängig von Sprache/Installation)
• Kontrollpunkt für Profilzuordnung: Systemsteuerung > Mail (Microsoft Outlook) > Profile anzeigen > Datendateien
• Windows-Anmeldeinformationsspeicher (Auswirkungen auf erneute Authentifizierung): control /name Microsoft.CredentialManager

Typische Fehlerbilder und ihre technische Signatur

Die drei häufigsten Symptomgruppen – Fehlen, Duplikate, Verzögerung – haben je nach Protokoll unterschiedliche technische Signaturen. „Fehlende E-Mails“ sind bei IMAP oft ein Ordner-/Abo- oder Filterthema, bei Exchange häufiger ein Cache- oder Ansichtsthema (inklusive Fokus/Weitere, Konversationsansicht oder serverseitiger Richtlinien wie Aufbewahrung). „Duplikate“ lassen sich bei IMAP oft auf doppelte Ablagepfade (Gesendet), Regeln in mehreren Clients oder mehrfaches Verschieben zwischen Ordnern zurückführen; bei Exchange spielen Add-ins, mobile Clients mit abweichender Ordnerlogik und kurzzeitige Konfliktauflösungen im Cache eine größere Rolle. „Verzögerungen“ sind bei Exchange häufig ein Hinweis auf eine hängende Client-Synchronisation oder ein begrenztes Offlinefenster, bei IMAP eher auf Verbindungsabbrüche, serverseitige Limits oder Ordner mit sehr vielen Elementen.

Grenzfälle: parallele Zugriffe und „Schattenzustände“ durch mehrere Clients

Parallele Zugriffe sind ein häufiger Verstärker, weil mehrere Clients Zustände unterschiedlich interpretieren oder Operationen zeitversetzt ausführen. Ein klassisches Muster ist die gleichzeitige Nutzung von Outlook (Cache), Outlook im Web und einem Smartphone-Client: Eine Regel verschiebt eine Nachricht, der Mobilclient markiert sie als gelesen, während Outlook den Ordner noch nicht vollständig aktualisiert hat. In IMAP-Umgebungen kommt hinzu, dass manche Clients Löschungen als „Markieren zum Löschen“ behandeln und erst später expungieren; in der Zwischenzeit wirkt eine Mail „doppelt“ oder „noch da“, obwohl der Serverzustand bereits im Übergang ist.

Für die spätere systematische Prüfung ist diese Abgrenzung entscheidend: IMAP-Probleme werden primär über Ordnerabos, Serverordnerzuordnung und Protokollzustände eingegrenzt, Exchange-Probleme über Cachekonsistenz (OST), Profilzustand und serverseitige Sichtbarkeit (OWA). PST-basierte Ablagen sind dagegen per Definition außerhalb der Synchronisation und müssen als separate Dateninsel betrachtet werden.

Ursache sauber eingrenzen: Serverzustand, Webmail-Vergleich, Zustellpfad und parallele Zugriffe (Mobilgeräte, Shared Mailbox, Regeln)

Fehlende, doppelte oder verspätet eintreffende E-Mails lassen sich nur belastbar beheben, wenn zuerst die Fehlerdomäne klar wird: Serverzustand (Mailbox/Transport), Zustellpfad (Gateway, Spam-/Quarantäne, Journaling) oder Client/Sync (Outlook-Cache, Mobilgeräte, parallele Zugriffe). Ein sauberes Vorgehen beginnt deshalb mit einem Vergleich zwischen Server-Sicht und Client-Sicht und endet erst, wenn eine Ursache eindeutig einem Pfadabschnitt zugeordnet ist.

Serverzustand prüfen: Ist die Nachricht überhaupt in der Mailbox angekommen?

Der erste Fixpunkt ist die serverseitige Wahrheit. Bei Exchange Online und On-Premises-Exchange bildet die Mailbox inklusive Ordnerstruktur den Referenzzustand; bei IMAP ist es der IMAP-Server samt serverseitigen Flags (z. B. \Seen, \Deleted) und UID-Stand. Wenn eine Nachricht serverseitig nicht existiert, kann kein Client sie „nachsynchronisieren“; dann liegt das Problem vor der Mailbox (Transport, Filter, Regeln) oder es handelt sich um eine Zustellung in ein anderes Postfach oder in einen anderen Ordner.

Serverseitig ist außerdem zu klären, ob Kapazitäts- oder Richtlinienthemen greifen: volle Postfächer, Aufbewahrungs-/Retention-Policies, automatische Archivierung oder Quarantäne. Bei Exchange Online beeinflussen zudem Transportregeln und Microsoft-Defender-Filter, ob Mails zugestellt, umgeleitet oder in Quarantäne verschoben werden. Für IMAP-Umgebungen sind serverseitige Sieve-/Filterregeln, Spam-Ordner und „Auto-Expunge“-Verhalten typische Ursachen für vermeintlich „verschwundene“ Inhalte.

• Exchange Online Message Trace (Admin): https://admin.exchange.microsoft.com (Bereich „Nachrichtenablaufverfolgung/Message trace“) zur Prüfung, ob und wann eine Mail zugestellt, abgewiesen, umgeleitet oder in Quarantäne überführt wurde.
• Quarantäne- und Spamprüfung: https://security.microsoft.com/quarantine sowie in der Mailbox die Ordner „Junk-E-Mail/Spam“, „Gelöschte Elemente“, „Wiederherstellbare Elemente“ (falls Berechtigungen vorhanden).
• Exchange PowerShell (Admin, wenn zulässig): Get-MessageTrace -RecipientAddress user@domain.tld -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date)
Get-MessageTraceDetail -MessageTraceId <id> -RecipientAddress user@domain.tld
• IMAP-Server-Sicht verifizieren: IMAP-Webmail oder Admin-Console des Providers; zusätzlich IMAP-Ordnerhierarchie und Server-Flags prüfen (z. B. ob Mails serverseitig bereits als gelöscht markiert und expunged wurden).

Webmail-Vergleich als Referenz: Ordner, Ansichten und Suchgrenzen

Ein Webmail-Vergleich dient als schnelle Trennung zwischen serverseitigem Zustand und Outlook-/Client-Darstellung. Dabei genügt nicht die Prüfung des Posteingangs. Häufige Abweichungen entstehen, weil Nachrichten durch Regeln in Unterordner verschoben wurden, im Fokus-/Sonstiges-Filter (Microsoft 365) anders einsortiert sind oder weil Outlook und Webmail unterschiedliche Such-/Ansichtsfilter verwenden (z. B. „Ungelesen“, „Unterhaltungen“, „Heute“).

Für Exchange sollte der Vergleich idealerweise mit Outlook im Web erfolgen, weil dort dieselbe Mailbox-Logik wie serverseitig sichtbar ist. Für IMAP gilt: Das Webmail zeigt die serverseitige Ordnerstruktur; wenn Outlook abweichende „Sonderordner“ (Gesendet/Entwürfe/Papierkorb) nutzt, kann eine falsche Zuordnung dazu führen, dass gesendete oder gelöschte Elemente in unerwarteten Ordnern landen oder doppelt auftauchen.

Zustellpfad nachvollziehen: Weiterleitungen, Gateways, Transportregeln

Wenn der Serverzustand uneindeutig ist, hilft die Rekonstruktion des Zustellpfads. Doppelte Mails entstehen häufig, weil eine Nachricht sowohl direkt als auch über eine Weiterleitung erneut zugestellt wird. Typische Auslöser sind parallele Weiterleitungen (Inbox-Regel plus serverseitige Weiterleitung im Tenant), extern vorgeschaltete Mail-Gateways mit Retry/Redelivery oder doppelte Connector-Routen. Verzögerungen entstehen dagegen oft durch Greylisting, Malware-Scans oder Transportwarteschlangen; die Nachricht kommt dann serverseitig später an und wirkt im Client „verzögert“, obwohl die Synchronisation korrekt ist.

• Headeranalyse: Im Webmail die Internetkopfzeilen („Message headers“) prüfen; wichtig sind Received:-Ketten, Return-Path, Authentication-Results und Hinweise auf erneute Einspeisung (z. B. gleiche Message-ID mit unterschiedlicher Received-Route).
• Mailbox-Weiterleitungen prüfen (Exchange Admin): Postfach-Eigenschaften in https://admin.exchange.microsoft.com (Weiterleitung/Forwarding) sowie serverseitige Inbox-Regeln (Client- und Server-Regeln) getrennt bewerten.
• Transportregeln und Connectoren (Admin): Exchange-Transportregeln („Mail flow rules“) und Connector-Konfigurationen auf doppelte Weitergabe oder BCC-Kopien prüfen; bei Hybrid zusätzlich Edge-/On-Prem-Logs berücksichtigen.

Parallele Zugriffe: Mobilgeräte, mehrere Clients, Shared Mailboxes und Regeln

Synchronisationsauffälligkeiten entstehen häufig nicht durch „kaputte Synchronisation“, sondern durch gleichzeitige Aktionen mehrerer Clients. Ein klassisches Muster: Ein Smartphone (Outlook Mobile oder native Mail-App) verschiebt eine Nachricht in einen Ordner, während Outlook am PC sie noch im Cache anzeigt; nach der nächsten Sync „verschwindet“ sie scheinbar. Ähnlich wirken Shared Mailboxes oder delegierte Postfächer: Wird dort mit mehreren Personen gearbeitet, führen Verschieben/Löschen, Kategorien oder „Als gelesen markieren“ zu schnellen Statuswechseln, die im lokalen Cache zeitversetzt sichtbar werden.

Bei IMAP verstärken unterschiedliche Client-Implementierungen diese Effekte. Manche Clients kopieren beim Verschieben zuerst und löschen anschließend (Copy+Delete), andere nutzen serverseitiges MOVE. In Kombination mit unterschiedlichen Papierkorb-/Gesendet-Ordnern und automatischem Bereinigen („Expunge“) erscheinen Mails kurzzeitig doppelt oder verschwinden nach dem nächsten Ordner-Refresh. Bei Exchange kann zusätzlich die Konversationsansicht den Eindruck von Duplikaten erzeugen, wenn gleiche Inhalte als unterschiedliche Elemente (z. B. Kopie in Shared Mailbox plus persönliche Kopie) in einer Unterhaltung gruppiert werden.

• Clientmatrix erstellen: Alle zugreifenden Instanzen erfassen (Outlook Windows, Outlook im Web, Outlook Mobile, native iOS/Android-Mail, weitere IMAP-Clients) und Zeitpunkt/Ordneraktion korrelieren; für Exchange zusätzlich Berechtigungen auf Shared Mailboxes dokumentieren.
• Mobilgeräte isolieren: Testweise Zugriff eines verdächtigen Geräts pausieren (z. B. Konto in der App entfernen oder Sync deaktivieren) und prüfen, ob Verschiebe-/Lösch-Ereignisse aufhören; für Exchange-Umgebungen sind Geräteübersichten im Admin-Umfeld relevant.
• Regeln unterscheiden: Outlook-Clientregeln versus serverseitige Regeln trennen; Indikator ist, ob Regeln auch wirken, wenn Outlook geschlossen ist. Bei Exchange Online zusätzlich automatische Weiterleitungen und Transportregeln gegenprüfen.
• Shared-Mailbox-Spezifika: In Outlook die Art der Einbindung berücksichtigen (Automapping vs. manuell, Cache für freigegebene Ordner); bei inkonsistenten Ansichten testweise in Outlook im Web gegenprüfen, weil dort kein OST-Cache die Darstellung verzerrt.

Outlook unter Windows 11 gezielt prüfen und korrigieren: Synchronisationsstatus, Sende/Empfangen, Ordner zurücksetzen, OST/PST prüfen ohne Profilbruch

Unter Windows 11 treten Synchronisationsfehler in Outlook häufig nicht „global“, sondern ordner- oder cachebezogen auf: einzelne Unterordner bleiben zurück, Elemente erscheinen doppelt, oder der Versand hängt, obwohl der Posteingang scheinbar aktuell wirkt. Eine systematische Prüfung beginnt deshalb innerhalb des Clients: Statusanzeigen, Protokollierung, Sende-/Empfangen-Gruppen und der Zustand der lokalen Datendateien (OST/PST) liefern konkrete Hinweise, ob Outlook nur verzögert nachzieht, lokal inkonsistent ist oder tatsächlich serverseitig keine vollständige Datenbasis erhält.

Synchronisationsstatus und Fehlerindikatoren in Outlook richtig lesen

Outlook blendet mehrere Statusquellen ein, die oft verwechselt werden. Die Statusleiste („Verbunden“, „Getrennt“, „Arbeitet offline“) beschreibt primär die Transportverbindung, nicht die inhaltliche Vollständigkeit einzelner Ordner. Für Exchange-Konten ist zusätzlich der Ordnerstatus relevant (Synchronisation einzelner Ordner, Konflikte, lokale Fehler), bei IMAP-Konten sind Serverantworten und lokale Sende-/Empfangen-Aktivität entscheidend. Eine häufige Ursache für „fehlende“ Nachrichten ist eine unbemerkte Einschränkung der lokalen Offlinevorhaltung (z. B. nur 3 Monate), kombiniert mit Suche oder Sortierung, die ausschließlich den lokalen Cache auswertet.

Für belastbare Hinweise sollten in Outlook drei Informationspfade zusammengeführt werden: die Verbindungsdiagnose, der Synchronisations-/Ordnerstatus sowie die Frage, ob ein Element nur lokal existiert (Entwürfe/Outbox) oder serverseitig tatsächlich angekommen ist. Bei Exchange Online ist der Vergleich mit Outlook im Web besonders wertvoll, weil er ohne lokalen Cache arbeitet. Bei IMAP ist ein Vergleich mit Webmail bzw. dem Serverpostfach ebenfalls zentral, um lokale Index- oder Cacheprobleme von echten Serverzuständen zu trennen.

Sende/Empfangen gezielt steuern: Gruppen, Ordner, erzwungene Synchronisation

Viele Verzögerungen entstehen nicht durch „defekte“ Konten, sondern durch Sende-/Empfangen-Konfigurationen, die bestimmte Ordner ausnehmen oder Zeitpläne zu großzügig setzen. Besonders bei IMAP kann ein nicht abonnierter Ordner (oder ein neu angelegter Unterordner, der nicht abonniert ist) den Eindruck erwecken, Nachrichten fehlten. Bei Exchange-Konten kann die Cached-Mode-Synchronisation im Hintergrund laufen, während die Ansicht bereits nutzbar ist; dabei sind einzelne Ordner mit hoher Elementanzahl, freigegebene Postfächer oder Onlinearchive typische Kandidaten für Nachlauf.

• Sende-/Empfangen-Gruppen prüfen: In Outlook unter Send/Receive die Gruppen-Einstellungen kontrollieren, insbesondere ob einzelne Ordner abgewählt sind und ob der Zeitplan zu selten auslöst; anschließend manuell auslösen über Send/Receive All Folders.
• IMAP-Ordnerabonnements verifizieren: In den IMAP-Ordneroptionen sicherstellen, dass relevante Ordner abonniert sind; fehlende Inhalte betreffen dann oft genau die nicht abonnierten Ordner (häufig Unterordner unter „Gesendet“, „Entwürfe“, „Archiv“).
• Sendestatus ohne UI-Störfaktoren beurteilen: Bei hängendem Versand Add-ins testweise deaktivieren (outlook.exe /safe) und erneut senden; bleibt die Nachricht im Postausgang, Authentifizierung/Verbindung und anschließend Datendatei-Integrität priorisieren.
• Cached Mode vs. Online-Ansicht abgleichen: Bei Exchange testweise eine Onlineprüfung durchführen (z. B. in Outlook im Web) und bei Verdacht auf Cache-Limit die Einstellung Mail to keep offline (falls administrativ erlaubt) auf einen größeren Zeitraum setzen.

Ordner zurücksetzen, ohne das Profil zu zerstören: Fokus auf betroffene Bereiche

Wenn nur einzelne Ordner „klemmen“ (z. B. Gesendet, Kalender, ein IMAP-Unterordner), ist ein kompletter Profil-Neuaufbau oft unnötig und risikoreich, weil Autovervollständigung, Signaturen, Add-in-Zustände oder benutzerdefinierte Einstellungen verloren gehen können. Stabiler ist ein Vorgehen, das zuerst den betroffenen Ordner bzw. die betroffene Ansicht isoliert: Ansichtsfilter, Gruppierungen und Suchordner können Inhalte scheinbar „verschwinden“ lassen, obwohl die Elemente im Ordner existieren. Erst wenn die Ansicht sauber ist, lohnt sich ein Reset der betreffenden Ordnerbeziehung oder eine lokale Cache-Neuerstellung.

• Ansicht und Filter zurücksetzen (ohne Datenverlust): Betroffenen Ordner öffnen und über View prüfen, ob Filter/„Unterhaltung“/Gruppierungen die Anzeige verzerren; bei Bedarf Ansicht auf Standard zurücksetzen (keine Serveränderung, reine Darstellungskorrektur).
• IMAP-Ordnerzuordnung für „Spezialordner“ prüfen: Falsche Zuordnungen führen zu doppelten „Gesendet“-Ordnern oder Entwürfen an unerwarteten Orten; serverseitige Ordner (z. B. „Sent“, „Sent Items“) müssen in Outlook konsistent abgebildet sein, sonst entstehen Duplikate beim Senden/Bewegen.
• Gezielte Cache-Neuerstellung statt Profilwechsel: Bei Exchange lässt sich der lokale Zustand häufig durch Neuanlage der OST erzwingen, ohne das Profil zu löschen: Outlook schließen, die OST-Datei im Profilpfad umbenennen (z. B. unter %LOCALAPPDATA%\Microsoft\Outlook\) und Outlook neu starten; Outlook baut die OST aus dem Serverpostfach erneut auf.
• Kalender/Kontakte mit Synchronisationskonflikten eingrenzen: Bei Exchange können Konflikte Elemente duplizieren oder „zurückspringen“ lassen; die Prüfung des Ordners Conflicts (falls vorhanden) und der Änderungszeitpunkte hilft, parallele Clients als Ursache zu bestätigen.

OST/PST unter Windows 11 prüfen: Integrität, Größe, Sperren und Reparaturpfade

Lokale Datendateien sind ein häufiger Beschleuniger für Symptome: Eine beschädigte PST erzeugt Dubletten oder fehlgeschlagene Verschiebungen; eine OST mit Inkonsistenzen zeigt alte Stände, obwohl der Server korrekt ist. Hinzu kommen Sperrsituationen durch Antivirus-Scanner, Backup-Agenten oder parallele Outlook-Instanzen, die die Datei kurzzeitig blockieren. Im ersten Schritt sollte geklärt werden, ob tatsächlich eine PST (lokal/POP/Archiv) betroffen ist oder eine OST (Exchange/Outlook.com in Cached Mode). Bei OST gilt: die Datei ist ein Cache und kann in der Regel neu erstellt werden; bei PST sind Reparatur und Backup vor Eingriffen zwingend.

• Datendateityp und Pfad ermitteln: In Outlook unter Kontoeinstellungen den Speicherort prüfen; typische Pfade sind %LOCALAPPDATA%\Microsoft\Outlook\ (OST) und %USERPROFILE%\Documents\Outlook Files\ (PST), Abweichungen sind in Unternehmensumgebungen möglich.
• OST neu aufbauen (Cache-Reset ohne Profilbruch): Outlook vollständig beenden (auch im Infobereich prüfen), OST umbenennen und Outlook starten; die Resynchronisation ist abhängig von Postfachgröße, Bandbreite und Anzahl freigegebener Ordner, deshalb Status und Ordnerfortschritt beobachten.
• PST reparieren statt neu erstellen: Vor Änderungen eine Kopie anlegen; danach die Microsoft-Reparatur SCANPST.EXE verwenden (Ort variiert je nach Microsoft-365-Apps-Installation) und nach der Reparatur gezielt den betroffenen Ordnerinhalt validieren (Suche, Sortierung, Elementanzahl).
• Dateisperren und I/O-Probleme eingrenzen: Bei wiederkehrenden Hängern Scanner-Ausnahmen für *.ost und *.pst gemäß Sicherheitsrichtlinie prüfen sowie parallele Prozesse/Backup-Zeitfenster; zusätzlich Windows-Ereignisanzeige auf I/O-Fehler kontrollieren (eventvwr.msc).

Wenn nach OST-Neuaufbau oder PST-Reparatur weiterhin exakt dieselben Elemente fehlen, liegt die Ursache mit hoher Wahrscheinlichkeit nicht im lokalen Speicher, sondern in der serverseitigen Ordnerstruktur, in Regeln/Retention oder in parallelen Clients, die Elemente verschieben oder löschen. Outlook liefert dann zwar Symptome, aber nicht die Quelle; eine saubere Eingrenzung erfordert den Vergleich mit Webzugriffen und serverseitigen Protokollen, bevor erneut auf Clientseite „repariert“ wird.