Shared Mailboxes
Plötzlich alles weg, was tun?
Michael Strohmaier / 19. Dezember 2022Freigegebene Postfächer (englisch "Shared Mailboxes") sind weit verbreitet und werden für unzählige, häufig geschäftskritische Prozesse verwendet. Diese Postfächer haben in der Microsoft Cloud viele Vorteile. Sie benötigen keine eigene Lizenz, können von mehreren Mitarbeitenden gleichzeitig genutzt werden und bieten einen zentralen E-Mail-Eingangspunkt.
Dementsprechend kritisch kann ein Ausfall dieser freigegebenen Postfächer für ein Unternehmen sein. Es handelt sich um Exchange Online Postfächer und die Erreichbarkeit wird doch sicherlich durch Microsoft sichergestellt, oder? Ja – generell ist diese Aussage auch richtig.
Kann es trotzdem zu einem Ausfall dieser Postfächer kommen? Ja – Das mussten wir gemeinsam mit einem unserer Kunden schmerzlich erfahren und es galt herauszufinden, wie das passieren konnte und wie man es in Zukunft verhindern kann.
Fangen wir von vorne an - Was ist passiert?
Wir bekamen die Meldung: „Einige unserer freigegebenen Postfächer sind nicht mehr erreichbar“. Nach initialem Troubleshooting stellte sich heraus, die freigegebenen Postfächer werden in Exchange Online nicht mehr als solche, sondern als E-Mail-Benutzende in der Kategorie „Kontakte“ angezeigt. Ein E-Mail-Empfang ist somit nicht mehr gegeben und Kontakte besitzen keine Postfächer mehr.
Teil des Troubleshootings war es, den Benutzenden der freigegebenen Postfächer eine Lizenz zuzuweisen. Dadurch wurde das Postfach als Benutzerpostfach angezeigt und nicht als freigegebenes Postfach. Über das Exchange Online Admincenter wurden diese Benutzerpostfächer wieder in freigegebene Postfächer konvertiert. Somit waren die Postfächer wieder verfügbar. Hier lag eine der Ursachen des Problems, dazu später mehr.
Jetzt galt es zuerst herauszufinden, wie jenes passieren konnte, um ein wiederholtes Auftreten zu verhindern. Das Troubleshooting und die Ursachenforschung wurden gemeinsam mit dem Microsoft Support durchgeführt.
Was war das Problem?
Die Kundenumgebung beinhaltet, wie einige, einen Azure AD Connect, um Benutzende und deren Attribute vom lokalen AD in das Azure AD zu synchronisieren. In diesem Szenario ist das lokale AD das führende System. Versucht man zum Beispiel ein Attribut eines Postfachs mit synchronisiertem Benutzer zu ändern, erhält man die folgende Fehlermeldung:
Dieses Verhalten ist richtig und auch so gewollt. Das führende System soll das lokale AD sein. Es gibt jedoch einen Vorgang, der häufig verwendet wird und diese Konstellation durcheinanderbringt.
Folgendes Szenario wird vielen bekannt sein: Ein Mitarbeitender verlässt das Unternehmen, was soll nun mit dem Postfach passieren? Man möchte für einen nicht-aktiven Benutzenden natürlich keine Lizenz bereitstellen. Die Lösung ist recht simpel. Man wandelt das Benutzerpostfach in ein freigegebenes Postfach um und sperrt die Anmeldung des Benutzenden. Das Exchange Online Admincenter hat dafür einen simplen Hyperlink und nur wenige Momente später ist das Postfach in ein freigegebenes Postfach umgewandelt.
In Exchange Online sieht auf den ersten Blick alles in Ordnung aus. Aber, wie bereits erwähnt, sollte in einer Umgebung mit synchronisierten AD Usern immer das lokale AD das führende System sein.
Die hier dargestellte Situation muss vorerst keine Probleme verursachen. Normale Azure AD Connect Synchronisationen haben hier auch keine Auswirkungen. Azure AD und Exchange Online haben ihre individuellen Verzeichnisdienste und diese werden nur bei „bestimmten Triggern“ miteinander synchronisiert. Also kann die fehlerhafte Konstellation über Monate nicht auffallen. Das lokale AD sowie Azure AD geht also von einer Usermailbox aus, Exchange Online jedoch von einer Shared Mailbox. Wird ein Sync zwischen Exchange Online und Azure AD getriggert, überschreibt Azure AD den Exchange Online Wert, denn: „In einer hybriden Umgebung ist immer das lokale AD das führende System“.
Zu diesem Zeitpunkt hat man also freigegebene Postfächer, die zu Benutzerpostfächern zurückkonvertiert wurden.
Warum sind diese Postfächer dann plötzlich unter Kontakten wiederzufinden?
Das ist relativ einfach: Ein freigegebenes Postfach benötigt keine Exchange Online Lizenz, das ist einer der Vorteile der freigegebenen Postfächer. In unserem Fall wurde jedoch das freigegebene Postfach in ein Benutzerpostfach zurückkonvertiert und ein Benutzerpostfach braucht eine Exchange Online Lizenz, sonst wird es deaktiviert. Durch das Fehlen der Lizenz wurden die Postfächer demnach deaktiviert und der Benutzende wird als E-Mail-Benutzer unter Kontakte angezeigt.
Was ist die richtige Methode, um ein Benutzerpostfach in ein freigegebenes Postfach zu konvertieren?
Das „RemoteUserMailbox“ Objekt in der lokalen Umgebung muss in ein „RemoteSharedMailbox“ Objekt umgewandelt werden. Das wird in einer lokalen Exchange PowerShell mit diesem Befehl durchgeführt:
Set-RemoteMailbox -Identity *** -Type Shared
Nach einem Azure AD Connect Sync, der auch manuell mit „Start-ADsyncSyncCycle“ gestartet werden kann, werden die Änderungen in die Cloud synchronisiert und das Postfach wird online in ein freigegebenes Postfach umgewandelt. Erst danach kann man die Lizenz vom Benutzenden entfernen. Somit sind die Attribute lokal, sowie in der Cloud, identisch.
Was muss bei betroffenen Postfächern unternommen werden?
Um betroffene Postfächer zu korrigieren, muss dem Benutzenden zuerst eine Lizenz vergeben werden. Dadurch wird jenem Benutzenden das Postfach wieder als Benutzerpostfach zugewiesen. Als Nächstes muss lokal der gleiche Befehl ausgeführt werden, um das Postfach in ein freigegebenes Postfach umzuwandeln:
„Set-RemoteMailbox -Identity *** -Type Shared”
Sie benötigen Unterstützung?
Bei Fragen oder Problemen können Sie sich gerne per E-Mail an support@abtis.de oder per Telefon unter 07231/4431200 an uns wenden oder Ihren vertrieblichen Ansprechpartner kontaktieren.
Jetzt Kontakt aufnehmen