Exchange Hybrid Shared Mailbox und AADConnect

Diese Seite beschreibt die Zusammenhänge von Shared/Raum-Postfächern mit AADConnect und Hybrid Mode und die Lösungsmöglichkeiten bei einem falschen Provisioning.

Auslöser

Auch in meiner Umgebung passiert es, dass Objekte nicht so angelegt werden, wie Microsoft das im Hybrid-Mode vorgesehen hat. Wenn Sie ein lokales Active Directory mit einem Office 365 Tenant per AADConnect verbunden haben, benötigen Sie einen lokalen Exchange Services zur Verwaltung der Objekte, die nach Office 365 synchronisiert werden. Sie können natürlich auch in Office 365 direkt neue Objekte anlegen und dann auch hinsichtlich Exchange dort verwalten.

Und genau das ist auch in meiner Umgebung passiert. Es wurde eine Shared Mailbox in der Cloud angelegt. Dass der UPN dabei dann auf "@tenantname.onmicrosoft.com" geendet hat, ist nicht aufgefallen, weil sich ja niemand mit dem Konto angemeldet hat. Wenn 99% der Anwender in der Cloud arbeiten, dann fällt das Fehlen des Empfängers in dem lokalen Adressbuch auch nicht wirklich auf. Auch dass dieses Postfach nicht per Mail aus dem Internet erreichbar war, war lange kein Problem bis nun doch die Erreichbarkeit aus dem Internet gefordert wurde.

Eingehende Mails empfange ich nicht über Office 365 und Exchange Online Protection sondern über meinen lokalen NoSpamProxy, der natürlich das lokale AD ausliest. Ohne passenden "Remote Shared Mailbox" Eintrag hat er die Mails an diese Adresse zurecht als "invalid recipient" abgelehnt.

Der alte Weg

Wenn Sie in so einer Umgebung eine Shared Mailbox oder auch eine Raummailbox in Office 365 anlegen wollten, dann war Anfang nur der folgende Weg vorgegeben (Stand April 2018)

  1. Anlegen der Shared Mailbox / Raums On-Premises
    Damit wird das Objekt lokal schon mal vorbereitet und richtig provisioniert. Auch AADConnect synchronisiert die Information in die Cloud
  2. Postfach in die Cloud verschieben
    Über den normalen Move-Request wird das Postfach dann nach Exchange Online verschoben. Im lokalen AD bleibt eine "Remote-Mailbox" zurück, die aber eine Shared Mailbox ist.

Das war natürlich unschön und konnte nicht lange so sein.

Der neue Weg

Mittlerweile wurden aber auch die Commandlets "New-RemoteMailbox" und "Enabled-RemoteMailbox" entsprechend erweitert, dass Sie mit den Parametern "-room" oder "-shared" den Typ ändern.

Der Befehl ist dann einfach:

New-RemoteMailbox `
   -Name "Shared1" `
   -UserPrincipalName shared1@msxfaq.de `
   -shared `
   -AccountDisabled

Auch das nachträgliche Ändern eines Postfachs in der Cloud zu einem Raum oder einer Shared Mailbox ist mittlerweile direkt möglich.

Set-RemoteMailbox `
   -Identity "Shared1"
   -type Shared

Sie müssen also das Postfach nicht mehr "zurück holen" und dann den Typ ändern und wieder in die Cloud migrieren.

Heilung (veraltet)

Diese Abschnitt ist als Archiv vorhanden aber nicht mehr erforderlich, das Microsoft mittlerweile die sinnvolle Lösung über die On-Premises PowerShell umgesetzt hat.

In meinem Umfeld gab es aber nun mal ein Postfach mit jede Menge Inhalte, die ich nicht mal zurück nach On-Premises schieben konnte, da es lokal gar keinen Gegenpart gab. Also hätte ich so oder so zuerst ein lokales Konto anlegen müssen, welches als "Remote Mailbox" das Gegenstück zum Office 365 Ressourcenpostfach ist. Warum dann nicht gleich das lokale Konto so bearbeiten, dass es dem Ziel entspricht? Dabei gibt es aber Herausforderungen:

  • Dubletten und Matching
    Ich möchte keine doppelten Konten haben und in Office 365 gibt es schon das Postfach. Wenn ich lokal ein Konto anlege, dann muss AADConnect eine Verbindung zum bestehenden Konto in der Cloud herstellen
  • Kein AzureAD-Datenverlust
    Durch den AADConnect wird natürlich das lokale AD-Konto "führend" was die Inhalte einiger AD-Felder betrifft. Insbesondere "Displayname" und "ProxyAddresses" sind hier interessant
  • Typ und Lizenz
    Nur eine "SharedMailbox" ist in Office 365 lizenzfrei. Wenn durch die Änderung Office 365 dieses Postfach falsch einstuft, dann beginnt die 30 Tage "Grace"-Period, nach der das Postfach tatsächlich auch gelöscht würde.

Daher bin ich vorsichtig vorgegangen.

  • AADConnect blockiert
    Zuerst habe ich dafür gesorgt, dass während der Anlage und Modifikation des lokalen AD-Kontos nicht AADConnect einen inkonsistenten Zwischenstand sieht. Wer AADConnect mit einem Filter betreibt, kann das Objekt natürlich ausschließen. Ich habe einfach AADConnect pausiert.
  • Neue „Remote Mailbox“ angelegt
    Dann habe ich eine neue Remote-Mailbox lokal angelegt, die die gleiche Mailadresse des Objekts in der Cloud hat. Wie Sie aus ADSync User Matching wissen, matched AADConnect neue Objekte anhand dieses Feldes.
New-RemoteMailbox `
   -UserPrincipalName shared1@msxfaq.net `
   -Name Shared1 `
   -password (ConvertTo-SecureString `
      -AsPlainText `
      -String "Super1Geheim!" `
      -Force`
   )
  • AD-Konto deaktiviert und verschoben
    Das neu angelegte AD-Konto habe ich dann aus "cn=Users" in eine vorbereiteter OU verlagert und natürlich das Konto deaktiviert.
  • Per ADSIEDIT die beiden Felder geändert
    Eine "remote Shared Mailbox" unterscheidet sich von einer normalen "Remote Mailbox" erst einmal nur durch die beiden folgenden Properties, die ich per ADSIEDIT flugs geändert habe
msExchRemoteRecipientType: 100
msExchRecipientTypeDetails: 34359738368
  • AADConnect wieder gestartet
    Wenn ich alles richtig gemacht habe, sollte AADConnect den neuen Benutzer finden und über das Metaverse in den Tenant übertragen und dort das bestehende Konto aktualisieren.

Das Ergebnis vorab: In meiner Umgebung hat alles wie erwartet funktioniert. Ich habe nun eine "Remote Shared Mailbox" im lokalen AD, die mit dem Office 365 Postfach per AADConnect verbunden ist.

Änderungen

Um diese Funktion zu kontrollieren, habe ich mit einem "Get-Mailbox" mit der Exchange Online Powershell die vorhandenen Shared Mailbox dokumentiert. Durch einen Vergleich mit den Änderungen nach dem AADConnect-Lauf bin ich recht sicher, dass dieser Weg möglich ist, auch wenn Microsoft dies zumindest offiziell nicht unterstützt.

Feld Alt Neu
UserPrincipalName

Shared1@msxfaq.onmicrosoft.com

Shared1@msxfaq.de
WindowsLiveID

Shared1@msxfaq.onmicrosoft.com

Shared1@msxfaq.de
MicrosoftOnlineServicesID

Shared1@msxfaq.onmicrosoft.com

Shared1@msxfaq.de
RemoteRecipientType

None

Migrated, SharedMailbox
UsageLocation

$null

Deutschland
StsRefreshTokensValidFrom

08.03.2018 13:15:15

10.04.2018 12:51:30
IsDirSynced

False

True
EmailAddresses

{smtp:Shared1@msxfaq.onmicrosoft.com, SMTP:Shared1@msxfaq.de}

{smtp:Shared1@msxfaq.net, smtp:Shared1@msxfaq.mail.onmicrosoft.com,

Alle anderen Felder in Office 365 sind nicht verändert worden und auch ein Vergleich mit einer Shared Mailbox in Office 365, die auf dem normalen Weg angelegt wurde, hat keine relevanten Abweichungen gezeigt.

Kontrolle der Lizenz

Am Anfang hatte ich darauf hingewiesen, dass eine Shared Mailbox zwar lizenzfrei ist, aber die Cloud das natürlich auch korrekt erkennen muss. Der einfachste Weg ist die Kontrolle per AzureAD PowerShell mit dem Befehl "Get-MSOLUser". Das Property "LicenseReconciliationNeeded" ist der Schlüssel:

(Get-MSOLUser -UserPrincipalName Shared1@msxfaq.de).LicenseReconciliationNeeded
False

Dieser Wert muss auf "$false" stehen. Wenn hier ein True steht, dann meint Office 365, dass eine Lizenz erforderlich ist aber der Benutzer keine hat. Wenn Sie dies nicht bemerken, dann wird die Mailbox nach 30 Tagen samt Daten gelöscht.

In meinem Fall ist hier kein Fehler passiert. Die Shared Mailbox benötigte keine Lizenz. Von anderen Blogs und Forenbeiträgen kenne ich aber Meldungen, dass dies irrtümlich auch mal ""true" sein kann. Es würde dann reichen, einmal eine Lizenz zuzuweisen und danach wieder zu entfernen, um die Lizenzerkennung wieder zu triggern.

Sonderfall Online Konvertierung

Wenn Sie im Exchange Online Admin Center einen Benutzer anwählen, dann ist ihnen vielleicht rechts der Punkt "Convert" aufgefallen:

Sie können damit eine normale Mailbox in eine "Shared Mailbox" umstellen und auch wieder zurück umstellen. Diese Änderung ist sowohl für "Cloud Only"-Benutzer aber ebenso für durch AADConnect verwaltete Benutzer möglich. Da AADConnect aber primär eine OneWay-Replikation ist, werden solche Änderungen nicht nach OnPremise geschrieben. Dort bleibt es dann eine "Remote Mailbox" wie bei der initialen Anlage. Sie wissen aber ja nun, wie sie dann auch On-Premises die beiden relevanten Felder anpassen. Denken Sie auch an die Anpassungen bezüglich der Exchange Lizenz.

Weitere Links