Vor kurzem hatten wir es bei einem Kunden mit einem sehr seltsamen Fall zu tun. Der Kunde hat eine Exchange 2016 Umgebung, Exchange Hybrid inkl. Hybrid Modern Auth ist aufgebaut, alle Postfächer befinden sich on-premises. Der Kunde hat Outlook for iOS für all seine Mitarbeiter ausgerollt, andere ActiveSync Applikationen sind nicht zugelassen. Etwas Besonderes ist noch, dass der Kunde einen Reverse Proxy inkl. Web Application Firewall (WAF) vorgeschalten hat.
Wie Sie vielleicht wissen, kommuniziert die Outlook for iOS App nicht direkt mit der Exchange Umgebung, sondern alle Daten werden über einen „Cloud Cache“ bei Microsoft, dem „MRS Service“, synchronisiert.
Analyse
Nach und nach meldeten sich Mitarbeiter bei uns, dass sie keine aktuellen E-Mails in der App sehen (z.B. nur vom Vortag), und der Kalender sei unvollständig. Nach den ersten Troubleshooting-Versuchen, die alle im Sande verliefen, mussten wir etwas tiefer einsteigen und konnten Folgendes feststellen:
- laut Mobile Device Statistics gab es noch keinen einzigen erfolgreichen Synchronisierungsversuch
- Das Löschen der Active Sync Device Partnership löst einen Full Sync aus, der zumindest einmalig aktuelle E-Mails in der App synchronisieren lässt
- im IIS Log und Active Sync Debug Log konnten wir dann aber tatsächlich erste Hinweise und Fehlermeldungen entdecken: „StoragePermanent„, „InvalidRecipientsException„, „MapiExceptionInvalidRecipients„
- Später konnten wir noch feststellen, dass diese Meldungen auch im Eventlog der Exchange Server auftauchen (Log = Application, Type = Warning, Source = MSExchange ActiveSync, Event ID = 1008)
Es sah danach aus, als würden ein paar korrupte Elemente in dem Postfach dafür sorgen, dass die komplette Synchronisation ins Stocken gerät. Die Suche nach der wirklichen Ursache des Problems gestaltete sich wiederum sehr schwierig, da die Logs nicht besonders viel zur Herkunft dieser Elemente hergaben.
Lösung
Letztlich konnten wir die Elemente im Kalender der betroffenen User lokalisieren. Das gelang uns mit MFCMapi – die betroffenen Elemente waren sehr alt und hatten nur eine Hand voll Attribute, viel zu wenig für ein validen Kalendereintrag. Es gab allerdings keinen einzigen Weg, diese Elemente zu löschen (weder MFCMapi, EwsEditor oder auch mittels Search-Mailbox). Die Lösung am Ende war:
- PST-Export des Postfachs (das korrupte Element lässt sich nicht exportieren)
- Rehome des Postfachs (Set-Mailbox -Identity ‚user‘ -Database ’new DB‘)
- Import der PST
Seitdem läuft die Postfachsynchronisierung mit Outlook for iOS einwandfrei, Kunde und Mitarbeiter waren wieder glücklich. Woher das Problem kam, ist nicht 100% sicher – die Vermutung liegt allerdings nahe, dass es mit der 3rd Party E-Mail-Archivierungs-Lösung des Kunden zu tun hatte.
