Exchange Nachprovisioning

Kleine Firmen und Startups arbeiten gerne mit Exchange Online und Microsoft 365 aber haben kein lokales Active Directory oder haben bislang auf ADSync verzichtet um keinen lokalen Exchange Server allein für das Management betreiben zu müssen. Mit den neuen Recipient Management PowerShell ist dies deutlich einfacher geworden, so dass Sie die Vorteile von ADSync nutzen können. Aber dazu sind Vorarbeiten erforderlich.

Ausgangssituation

Für die weiteren Betrachtung gehen wir davon aus, dass die Firma einen Office365/Microsoft 365 Tenant mit Exchange Postfächern hat. Ohne ADSync sind das auch alles "Cloud Only"-Benutzer, die in der Cloud eben nicht durch ADSync angelegt oder verwaltet werden. Meist dürfte der Administrator die Benutzer über admin.microsoft.com manuell anlegen und mit einem Kennwort und einer Lizenz versehen.

Das funktioniert erstaunlich gut für wenige Benutzer, bei denen SingleSignOn nicht relevant ist oder es überhaupt kein lokales AD gibt. Die Anwender müssen sich halt zweimal anmelden, wenn Sie ihre Zugangsdaten nicht im Browser oder Windows Tresor speichern.

Ohne ADSync kann der Administrator auch einfach unter https://admin.exchange.microsoft.com die Exchange Eigenschaften der Konten verwalten. Das gilt insbesondere für die Pflege von zusätzlichen Mailadressen (Secondary ProxyAddresses).

Solange kein ADSync installiert ist, kann so eine Firma natürlich auch ein lokales Active Directory installieren und nutzen, z.B. für lokale Dateiserver oder Gruppenrichtlinien. Das ist erst einmal nicht schädlich.

Lokales AD führt

Firmen wachsen aber und mit der Zunahme der Anwender, Gruppenmitgliedschaften etc. wird eine Kopplung der Cloud mit einem lokalen Active Directory immer mehr gewünscht. Es ist nicht nur der Administrator, der sich eine Doppelarbeit spart. Viel mehr ist die Datenkonsistenz hier wichtig, z.B. dass die Stammdaten (Straße, Ort, Telefonnummer, Gruppenmitgliedschaften etc.) synchron sind. Auch die Änderung von Kennworten muss der Anwender mit der richtigen ADSync-Konfiguration nur einmal im lokalen AD machen.

Sobald auch die lokalen AD-Objekte die Mailadressen aus der Cloud haben, können auch anderen lokalen Produkte diese Informationen nutzen. Ich kenne durchaus einige "Scan zu Mail"-Geräte, die per LDAP das lokale AD auslesen um ein Adressbuch anzuzeigen. Ohne entsprechende Informationen im AD funktioniert dies nicht. Auch Outlook liest beim ersten Start das Feld "Mail" aus um direkt eine Verbindung zu Postfach zu versuchen. Ohne diese Information muss der Benutzer seine Mailadresse manuell eingeben.

Sie sehen also schon, dass mit dem Wachstum einer Firma oder der Weiterentwicklung eines Pilot/Test-Betriebs von Microsoft 365 in einen Regelbetrieb das lokale Active Directory eingebunden werden muss.

Leider ist aktuell nur die Richtung "AD zu AzureAD" möglich. Noch kann das AzureAD nicht in das lokale AD zurückschreiben.

ADSync ändert die Regeln

Der Einsatz von ADSync ist für kleinere Firmen mit lokalen AD aber ohne Exchange Server ein echtes Problem, denn sobald der Tenant in den "DirSync"-Mode geschaltet wird, können Sie in der Cloud z.B. die Mailadressen der Postfächer nicht mehr verwalten. Exchange Online erwartet, dass diese Informationen aus dem lokalen AD kommen. Dort gibt es allerdings noch keine passenden Informationen.

Das ist erst einmal nicht schlimm, denn wenn es im lokalen AD keine Inhalte gibt, dann hat ADSync nichts auszulesen und überscheibt auch nichts in der Cloud.

Achtung: Wenn Sie im lokalen AD das Feld "Mail" oder ProxyAddresses" schon gepflegt haben, dann übernimmt ADSync diese Werte zu Exchange Online.

Der klassisch Betrieb eines Microsoft 365 Tenant mit Exchange ist natürlich ein Exchange Hybrid-Mode. Dazu mussten Sie aber bis zum 20. Apr 2022 einen lokalen Exchange Server installieren. Der war kostenfrei (Siehe Hybrid Connector Server) aber mit dem Exchange 2019 CU12 vom 20. April 2022 gibt es nun eine Exchange Management Rolle. Damit haben Sie "nur" eine  Recipient Management PowerShell zur Verwaltung was aber auch ausreicht.

Nachkonfiguration

Die große Herausforderung einer nachträglichen Ankopplung von Exchange Online an ein lokales AD besteht in der Konfiguration der der lokalen Objekte mit den gleichen Exchange Eigenschaften, wie diese auch in der Cloud gesetzt sind. ADSync schreibt ja fast nichts (Siehe ADSync Bidirektional) in das lokale AD zurück und wenn sie ADSync sogar schon vor der lokalen Exchange Vorbereitung installiert haben, dann hat das ADSync-Setup noch nicht die Exchange Schema-Erweiterung berücksichtigen können. Damit haben wir nun einige Aufgaben vor uns, die Umgebung "Ready" zu machen

Exchange Vorarbeiten

Zuerst installiere ich im lokalen Active Directory entweder einen Exchange Server oder zumindest die Recipient Management PowerShell, damit ich die Empfänger im lokalen Active Directory verwalten kann. In der Folge beschränke ich mich auf die Nutzung der Recipient Management PowerShell.

Durch die Installation auf einem Windows10/11 oder Windows 2019/2022-Server bekommen Sie nicht nur ca. 2,5 GB Programmcode auf das System sondern auch die Exchange Schema Erweiterung und die Konfiguration einer Exchange Organisation. Im Grunde sind das aber nur ein paar LDAP-Einträge, Windows Gruppen und Berechtigungen.

Die Installation ist auf der Seite Recipient Management PowerShell beschrieben.

Exchange Online Empfänger abgleichen

Nun kommt die eigentlich wichtige Aufgabe. Ich muss für jeden Exchange Empfänger in der Cloud das passende lokale AD-Objekt finden. Wichtig sind hier zuerst die Felder "mail" und "ProxyAddresses". Aber auch der Empfängertyp ist wichtig, denn es gibt neben den Cloud-Postfächern, die On-Premises dann eine RemoteMailbox werden auch noch Verteiler und Kontakte.

Wir sollten also zuerst die Exchange Online-Empfänger aus dem Tenant extrahieren. ich beschränke mich hier aber nur auf die Objekte, die auch im lokalen Vorhanden sind:

  • UserMailbox
    Das sind die normalen Postfächer
  • MailUniversalSecurityGroup und MailUniversalDistributionGroup
    Dies sind Mailverteiler oder Office Group

Die Herausforderung ist dann natürlich, zu dem CloudOnly-Objekt auch ein On-Premises Objekt zu finden. Die Herausforderung hat aber schon das ADSync-Admin bei der Einrichtung. Siehe ADSync User Matching. Wenn Sie vorab schon ADSync aktiviert habe, dann hat ADSync versucht die Objekte zu matchen. Das kann ein "HardMatch" anhand eines vorhandenen SourceAnchor sein oder bei Benutzer auch der UPN (wenn aktiviert) oder das Feld Mail.

Ich bin ein Freund der Mailadresse im Feld "mail", da Sie eindeutig sein muss und mit den normalen Verwaltungswerkzeugen gepflegt werden kann.

In der Folge kann ich per Exchange Online PowerShell einfach die Objekte aus der Cloud holen, und dann die Werte in das lokale AD mit der lokalen Exchange PowerShell schreiben.

Hier mal ein Ausschnitt für die Neuaktivierung von bestehenden lokalen AD-Konten zu "Remote Mailboxen", wenn bei bei den lokalen Benutzern zumindest das Feld "mail" als primärer Schlüssel gepflegt ist.

# Verbindung zu Exchange Online herstellen
Connect-ExchangeOnline

# lokales Exchange Recipient Snapin einbinden
Add-PSSnapin  Microsoft.Exchange.Management.PowerShell.RecipientManagement

foreach ($recipient in Get-EXORecipient) {
   if ($recipient.RecipientTypeDetails -eq "UserMailbox") {
      $remoteroutingaddress = recipient.EmailAddresses | where {$_.endswith("onmicrosoft.com")}[0]
      if (!$remoteroutingaddress) {
         Write-Warning "Skip Mailbox $($recipient.PrimarySMTPAddress). No OnMicrosoft.com Address found"
      }
      else {
         Write-Host "Try to enable RemoteMailbox"
         Microsoft.Exchange.Management.PowerShell.RecipientManagement\Enable-Remotemailbox `
            -Identity $recipient.PrimarySmtpAddress `
            -RemoteRoutingAddress remoteroutingaddress `
            -Displayname $recipient.Displayname `
            -Alias $_recipient.alias
      }
}

Das Skript wirft natürlich Fehler, wenn der Benutzer schon als RemoteMailbox oder anderen Objekte für Exchange aktiviert ist oder es kein passendes Objekt gibt. Aus Gründen der Übersichtlichkeit und Einfachheit habe ich hier keine Fehlerbehandlung eingebaut. Ich habe zudem auf Räume, Ressourcen und Shared-Mailboxen verzichtet, denn ich gehe davon aus, dass diese auch weiterhin in Exchange Online als "CloudOnly-Empfänger gepflegt werden

Vergleichbar können Sie natürlich auch die Gruppen im lokalen AD mit den für Exchange Online relevanten Eigenschaften versehen. Wobei auch dies nur für Gruppen relevant ist, die aus dem lokalen AD kommen. Alles was sowieso "CloudOnly" verwaltet wie wie z.B. Microsoft Teams, Office Groups oder auch Verteiler in Exchange Online und nicht mit einer lokalen Sicherheitsgruppe oder Mailverteiler abgestimmt werden müssen, brauchen Sie auch nicht zu provisionieren.

Zukünftige Konfiguration

Nachdem Sie nun ADSync eingerichtet und die relevanten Exchange Online Objekte auch lokal mit einem Objekt versehen haben, können Sie auch wieder die Cloud-Eigenschaften über dieses lokale AD-Objekt verwalten. Wer keinen lokalen Exchange Server betreiben will, macht dies dann einfach über die Exchange Management Rolle umsetzen. Auf Recipient Management PowerShell habe ich die Befehle weiter beschrieben. Mittlerweile gibt es auch die erste GUI für die Verwaltung der lokalen Exchange Objekte.

Weitere Links