Recipient Management PowerShell

Seit dem 20. April 2022 (Ex2016/2019 20.04.2022 Update) erlaubt Microsoft die Verwaltung von Exchange Empfängern allein mit der Exchange Management Rolle. Sobald sie ihren Microsoft 365 Tenant mittels ADSync im "DirSync-Mode" betreiben, können Sie in Exchange Online leider keine Empfänger mehr verwalten, da Daten wie Mailadresse, ProxyAddresse etc. zwingend aus dem lokalen AD verwaltet werden müssen. Allerdings fällt der Exchange Server und damit die komplette Hybrid-Bereitstellung weg, was Hardware, Software und vor allem Arbeit für Betrieb, Monitoring, Patching etc. spart und damit auch die Sicherheit erhöht.

Der Schwerpunkt dieser Seite liegt auf der Verwaltung von Exchange Online Empfängern mit ADSync und ohne lokalen Exchange Server. Sie können die Exchange Management PowerShell natürlich auch mit einem lokalen Exchange Server unter Umgehung von RBAC verwenden, wenn ihr Konto ausreichende Berechtigungen hat.

Umgebung

Eine Exchange Online Umgebung ohne lokalen Exchange Server aber Active Directory und ADSync sieht vereinfacht wie folgt aus:

  • Domain mit DC und Exchange Schema Erweiterung
    DAS "passiert "alleine, wenn Sie die Exchange Management Rolle von Exchange 2019 CU12 oder höher installieren
  • ADSync/DirSync Kopplung
    Die Benutzer und Gruppen im lokalen AD werden durch eine lokale ADSync / AADConnect-Installation oder AzureAD Cloud Sync mit dem Tenant synchronisiert
  • Verwaltung im lokalen AD
    Durch den Verzeichnisabgleich sind die Exchange Empfänger in der Cloud in vielen Aspekten "ReadOnly"

Mangels lokalem Exchange Server gibt es aber keine Hybrid-Bereitstellung, keine lokalen Connectoren zur Übertragung von Mails oder Exchange Server Prozesse. Die Verwaltung der Empfänger erfolgt allein durch den Management-PC, auf dem die  Exchange Management Rolle von Exchange 2019 CU12 oder höher installiert ist.

Management Konzept

Ehe Sie mit der Installation losstürmen, sollten Sie sich überlegen, womit sie was verwalten. Es gibt mit Exchange nicht nur Postfächer sondern auch Verteiler und Kontakte. Wenn Sie keinen lokalen Exchange Server mehr haben, dann könnte Sie sich überlegen, einige Objekte als "Cloud-Only"-Objekte zu verwalten.

Objekt DirSync CloudOnly

Benutzer

Wenn Sie ADSync nutzen, dann dürfte die Mehrzahl der Benutzer auch durch ADSync in der Cloud verwaltet werden und dort "ReadOnly" sein. Jede weitere Verwaltung muss hier OnPremises erfolgen.

Natürlich könnten Sie auch mit "CloudOnly"-Benutzern arbeiten und wenn Sie kein lokale AD haben, dann ist das sogar der einzige Weg. Sobald sie aber ein lokales AD mit ADSync haben, sind bei meinen Kunden nur noch administrative Konten ein CloudOnly User. Und die haben kein Postfach.

Gruppe/Verteiler

Verteiler, nicht zu verwechseln mit Office Groups oder Microsoft 365 Gruppen/Teams, können Sie im AD verwalten, für Exchange aktivieren und dann auch in Exchange Online nutzen. Sie haben einen synchronen Datenbestand abre die Cloud-Objekte folgende dem lokalen AD.

Wenn Verteiler nur in Exchange Online verwaltet werden, dann können Sie dies per BRowser oder sogar Outlook an die "Besitzer" delegieren. Der Ansatz ist gut, wenn Sie die Gruppen nicht lokal für andere Zwecke, z.B. Mailrouting, ACLS etc brauchen. Es gibt einige Kunden, die nach dem Rückbau der lokalen Exchange Server auch die Verteiler in Exchange Online neu angelegt und dann lokal gelöscht haben.

Kontakt

MailContacts im lokalen AD werden ebenfalls durch ADSync in die Cloud repliziert. Sie stehen dort regelmäßig mit Gastkonten in der Cloud im Konflikt, die die gleiche SMTP-Adresse belegen. Wenn lokal niemand diese Information benötigt, dann brauchen Sie diese Objekte nicht mehr im lokalen AD

In Excange Online können sie Kontakte anlegen, die Sie übrigens in https://portal.azure.com nicht finden. Wenn Sie die Objekte aber nicht im lokalen AD für andere Zwecke brauchen, ist es durchaus ein gangbarer Weg diese Empfänger nur in Exchange Online zu verwalten.

Denken Sie aber immer daran, dass die Cloud-Only-Objete nicht im lokale Active Directory vorhanden sind und daher von lokalen Diensten nicht gefunden werden. Das kann z.B. Faxserver, Scan2Mail-Lösungen aber auch lokale Spamfilter betreffen, die gerne per LDAP das lokale AD befragt haben. Das kann ein Grund sein, die Elemente doch wieder im lokalen AD zu verwalten

Exchange Management Shell starten

Die Installation der Management Shell ist schnell erfolgt: Sie starten SETUP von der Exchange 2019 CU12 oder höher und wählen einfach nur die "Management Rolle" aus. Weitere Beschreibungen dazu finden Sie auf. Exchange Management Rolle. Wenn sie das Setup auf einem Server in einem Active Directory vornehmen, in dem es bislang noch keine oder sehr alte Exchange Installation gegeben hat, dann wird das Setup einfach nur die Admin-Tools installieren und ihnen Icons im Startmenü anlegen, die nicht wirklich funktionieren. Häufige Fehler sind:

  • Start der normalen Exchange PowerShell über das Startmenü
    Ds funktioniert nicht, da sich diese PowerShell mit einem nicht vorhandenen Exchange Server verbinden will.

Stattdessen sollten Sie eine normale PowerShell ohne Exchange starten und das erforderliche SnapIn einbinden

Add-PSSnapin  Microsoft.Exchange.Management.PowerShell.RecipientManagement

Es kann sein, dass das Einbinden gelingt, aber jeder Aufruf mit dem folgenden Fehler scheitert:

"Couldn't find the Enterprise Organization container"

Die Ursache hier hier, dass es im lokalen Active Directory Forest keine Exchange Konfiguration gibt oder sie nicht genug Rechte haben

Cannot write to the Exchange organization container [GlobalServerInstall]
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/ms-exch-setupreadiness-globalserverinstall?view=exchserver-2019

Die Lösung: Sie machen ein "PrepareAD". Natürlich müssen Sie dazu die Exchange Voraussetzungen erfüllen, wie z.B.:

  • Ausreichend aktueller Forest Functional Mode (FFM)
    Bei Exchange 2019 ist das noch Windows 2012R2 oder höher
  • Berechtigungen Schema Admin + Enterprise Admin
    Sonst kann das Setup die erforderlichen Änderungen nicht nachholen. Vergessen Sie nicht, diese Rechte nach dem Setup wieder zu entfernen
  • Weitere Voraussetzungen
    Es können noch andere Dinge schief gehen. Schauen Sie in die ExchangeServerSetup.log-Datei nach den Details

Danach sollte folgender Aufruf in ihrem Active Directory die erforderlichen Vorarbeiten vornehmen:

<cd>:\setup /PrepareAD /OrganizationName:"First Organization" /iacceptserverlicenseterms_DiagnosticsDataOFF

Nachdem das Setup erfolgreich durchgelaufen ist, haben wir ein Exchange Schema, die Verwaltungstools aber noch keine Konfiguration.

Exchange Grundkonfiguration

Danach können Sie aber immer noch keine RemoteMailbox anlegen, denn auch hier kommt wieder ein Fehler wie z.B.:

The following Error occured during validation in agent "RUS Agent": Failed to valid the ProxyAddresTemplate..........Unable to create the e-mail address.  for type "SMTP". Unable to load address module....

Das passiert, wenn Sie die PowerShell nicht als Administrator gestartet haben. Wenn die Exchange PowerShell keine Verbindung zu einem Exchange Server nutzen kann, dann kann sie auch kein RBAC nutzen und muss alle Aktionen selbst mit den Berechtigungen des angemeldeten Benutzers durchführen.

Nachdem Sie die PowerShell nun als Administrator gestartet haben, können Sie immer noch eine Empfänger in Exchange Online anlegen und verwalten, da die lokale Konfiguration nichts über die Cloud weiß. DAs müssen wir nun auch noch nachholen:

Aktion Erledigt

RemoteDomains

Wir müssen der lokalen Exchange Konfiguration die Domänen in der Cloud mitgeben und zumindest die "Microsoft Exchange Online Routing Address" -Domain <tenantname>.mail.onmicrosoft.com als TargetDeliveryDomain aktivieren.

New-RemoteDomain `
   -Name msxfaq.mail.onmicrosoft.com `
   -Domainname msxfaq.mail.onmicrosoft.com 

Set-RemoteDomain `
   -Identity msxfa.mail.onmicrosoft.com `
   -TargetDeliveryDomain $true

Sie können auch noch weitere Domains anlegen. Wenn es aber lokal keinen Exchange Server gibt, hat dies keine Auswirklungen. Nur die Routingdomain muss eingetragen werden, da z.B. *-remoteMailbox" das Feld "RemoteRoutingAddress" gegen diese Liste prüft.

Accepted Domain

Der nächste Schritt ist die Pflege der AcceptedDomains, ohne die ich im darauffolgenden Schritt keine Empfängerrichtlinien konfigurieren kann.

New-AcceptedDomain -NaNew-AcceptedDomain -Name msxfaq.mail.onmicrosoft.com -domainname msxfaq.mail.onmicrosoft.com

Empfängerrichtlinien

Damit die Commandlets zur Empfängerverwaltung auch wissen, wie die Mailadressen zu bilden sind, und auch die Exchange Online Routingaddresse dazu kommt, passe ich mindestens eine Richtlinie an. Das macht ansonsten der HCW - Hybrid Configuration Wizard.

Set-EmailAddresspolicy `
   -Identity "Default Policy" 
   -EnabledEmailAddressTemplates "SMTP:%g.%s@msxfaq.de","smtp:@msxfaq.onmicrosoft.com","smtp:@msxfaq.mail.onmicrosoft.com"

Ich kann natürlich noch weitere Richtlinien anlegen und an verschiedene OUs binden.

Ich gehe davon aus, dass es aktuell noch keine Empfänger gibt. Ansonsten müssen Sie ein Update-Recipient nachschieben und ausgenommene Empfänger manuell versehen.

Damit sind aber nun alle Vorarbeiten erfolgt, um die Empfänger im lokalen AD so zu verwalten, dass ADSync diese in die Cloud replizieren kann.

ADSync aktualisieren

Wenn Sie ADSync und den Verzeichnisabgleich zum Tenant schon vor der Installation der Exchange Management Shell installiert und konfiguriert haben, dann hat ADSync damals noch kein Exchange Schema gefunden und daher die erforderlichen Exchange Regeln noch nicht berücksichtigt. In dem Fall müssen Sie nun einmal auf ihrem ADSync-Server das Setup erneut starten, das Schema einlesen und dann die Hybrid-Checkbox aktivieren.

Damit wird sichergestellt, dass ADSync auch die für Exchange relevanten Felder mit in die Cloud synchronisiert. Das macht ADSync nämlich nur bei der Installation und legt passende Regeln an. ADSync repliziert ansonsten "nur" eine Teilmenge, z.B. "mail" und "ProxyAddresses", der Felder aber die Felder "msExchRecipientTypeDetails" und msExchRemoteRecipientType sind erst nach der Schema Erweiterung vorhanden.

Regeltätigkeiten

Die Exchange Management Rolle bringt aktuell keinerlei GUI, weder als MMC noch als Snapin für Active Directory Users&Computers oder Webseite mit. Sie müssen die Empfänger per "lokaler PowerShell" verwalten. Aber auch das ist eigentlich nicht schwer, denn es gibt nur ganz wenige Tasks, für die Sie sich die Befehle merken müssen und mit dem "Exchange Recipient Admin Center https://github.com/spgoodman/ExchangeRecipientAdmin " gibt es doch wieder eine GUID.

Die Aktionen sind eigentlich nur für Objekte relevant, die es im lokalen AD gibt und zugleich auch in Exchange Online verwendet werden, z.B. reguläre Benutzer und vieleicht Gruppen. Alle Exchange Objekte, die sie im lokalen Active Directory sowieso nicht benötigen, z.B. Räume, gemeinsame Postfächer (SharedMailbox) und selbst Mailverteiler können sie auch als "Cloud Only"-Objekte direkt in https://admin.exchange.microsoft.com oder per Exchange Online PowerShell verwalten. Nur Objekte, die durch ADSync aus dem lokalen AD in die Cloud repliziert werden, müssen Sie im lokalen AD verwalten.

Dazu reichen wenige Befehle:

Aufgabenstellung Beschreibung

Powershell Starten

Add-PSSnapin  Microsoft.Exchange.Management.PowerShell.RecipientManagement

Starten Sie auf dem Computer, auf dem Sie die Management Tools installiert haben, eine PowerShell 2 bis 5.1. Die neue PowerShell Core (6.x und 7.x) sind nicht geeignet. und binden Sie das Exchange Snapin manuell ein.

Empfänger auflisten

# Empfänger auflisten

Get-DistributionGroup
Get-MailContact
Get-MailUser
Get-RemoteMailbox

Leider gibt es das Commandlet "Get-Recipient" gerade nicht in der reduzierten Powershell. Daher müssen wir die unterschiedlichen Elemente einzeln abrufen.

Benutzer für Exchange Online aktivieren

Enable-RemoteMailbox `
   -Identity user1 `
   -PrimarySMTPAddress user1@msxfaq.de `
   -RemoteRoutingAddress user1@msxfaq.de

Ich gehe davon aus dass Sie schon heute einen Weg kennen, neue Anwender als AD-Konto anzulegen, z.B. mit der MMS für AD Benutzer und Computer und sie dieses bestehende Konto nur für Exchange Online aktivieren wollen. Dazu nutze ich einfach Enable-Mailbox mit dem SamAccountName oder UPN. Ich gebe auch die primäre Mailadresse und eine Zieladresse vor.

Beim klassischen Hybrid-Mode ist die "RemoteRoutingAddress" normalerweise in der Form "alias@<tenantname>.mail.onmicrosoft.com". Das Feld ist für die Cloud selbst aber irrelevant.

Im Hintergrund addiert das Commandlet die Werte in den lokalen AD-Benutzer und es dauert ein paar Minuten, bis die Werte in Exchange Online erscheinen.

Sie haben nur 30 Tage Zeit, dem neuen Postfach in Exchange Online uach eine Lizenz zuzuweisen, ehe es sonst wieder gelöscht wird.

Das Commandlet "Enable-Mailbox" gibt es in der reduzierten Exchange PowerShell gar nicht, so dass Sie den Fehler nicht begehen können.

Zusätzliche Mailadressen

# Sekundäre Adresse addieren
Set-RemoteMailbox `
   -identity user1 `
   -EmailAddresses @{add="user1.demo@msxfaq.de"}
# Sekundäre Adresse entfernen
Set-RemoteMailbox `
   -identity user1 `
   -EmailAddresses @{remove="user1.demo@msxfaq.de"}

Manchmal soll ein Empfänger noch weitere Mailadresse bekommen oder wieder verlieren. Auch das geht per PowerShell:

Postfach entfernen

Disable-RemoteMailbox `
   -identity user1

Über ein Disable-RemoteMailbox entfernen wir beim Benutzer die Exchange Eigenschaften und ADSync entfernt diese aus der Cloud. Zur Vollständigkeit sollten Sie in der Cloud auch die Lizenz entfernen. Dies ist nicht erforderlich, wenn Sie das AD-Objekt komplett löschen. Dann können Sie sich auch den Disable-RemoteMailbox sparen.

Verteiler aktivieren und deaktivieren

Enable-Distributiongroup `
   -Identity Gruppe1 `
   -PrimarySMTPAddress gruppe1@msxfaq.de
Disable-Distributiongroup `
   -Identity Gruppe1

Mailverteiler sind "Gruppen" im lokale Active Directory, die sie auch für Exchange aktivieren können. Eine "TargetAdresse" gibt es hier nicht, denn Exchange Online bekommt ja die Mails und verteilt sie.

Wenn Sie keine Kopplung der lokalen AD-Gruppen mit Verteilern in der Cloud benötigen, dann können Sie darauf auch verzichten und direkt "Cloud Only" Gruppen in Exchange Online unter https://admin.exchange.microsoft.com verwalten.

Auf der Seite Exchange Management Rolle habe ich die Installation und die Liste der verfügbaren Commandlets veröffentlicht.

Wenn Sie weitere Fälle haben, für die Sie eine Beschreibung wünschen, dann schreiben Sie mir doch einfach auf Kontakt

Recipient Management GUI

Nicht jeder Administrator ist nun erfahren im Umgang mit der PowerShell und speziell kleinere Firmen, bei denen nur selten Änderungen erforderlich sind, müssen dann doch wieder nachschlagen oder sind verunsichert ob der Funktionsfülle und dem Risiko einen Fehler zu begehen. Ist war aber nur eine Frage der Zeit, bis erste Entwickler sich dem Problem angenommen haben und eine GUI für die Recipient Management PowerShell entwickelt haben.

Die erste GUI wurde wohl von Steve Goodmann in weniger als einem Monat seit dem Release entwickelt. Sie ist in PowerShell geschrieben und wird auf dem Computer ausgeführt, auf dem Sie ansonsten die Exchange PowerShell nutzen würden. Technisch startet es aktuell aber noch einen lokalen Webserver in PowerShell, der dann HTML, JS, Images ausführt und die Daten für das WebUI ausliefert und Aktionen annimmt. Der komplette Code läuft n ihrem Benutzerkontext.

Die Bilder auf dem Blog von Practical365 sind schon vielversprechend und weitere Funktionen sind schon angedacht

https://GitHub.com/spgoodman/ExchangeRecipientAdmin

Support Statement

Ehe ich aber auf die Regeltätigkeiten und deren Befehle eingehe und zusätzlich ein paar seltener genutzte Befehle beschreibe, möchte ich auf ein paar Details eingehen.

  • DirSync
    Diese Seite ist nur zutreffend, wenn Sie Benutzer und Gruppen aus dem lokalen Active Directory in den Tenant synchronisieren. Hierbei gibt es aber drei Unterarten:
    1. Lokaler ADSync ohne ExHybrid Checkbox
      Die haben den ADSync installiert und die Checkbox für Exchange Hybrid nicht aktiviert, da sie ja keinen Exchange Server haben
    2. Lokaler ADSync mit ExHybrid Checkbox
      Ihr ADSync hat die Checkbox bei Exchange Hybrid aktiv, weil sie z.B. früher einen Exchange Server hatten, der aber zurückgebaut wurde
    3. AzureAD Cloud Sync
      Sie nutzen gar nicht mehr ADSync, sondern direkt den neuen Sync aus der Cloud
  • Exchange Hybrid
    Auch wenn Sie keinen Exchange Server mehr betreiben, kann ihre Umgebung zwei Varianten:
    1. Kein Exchange Hybrid
      Sie haben mangels Exchange Server nie eine Hybrid-Bereitstellung mittels HCW eingerichtet.
    2. Exchange Hybrid ohne Server konfiguriert
      Vielleicht war ja mal Exchange Hybrid konfiguriert aber die Exchange Server sind schon lange nicht mehr da aber die Einstellungen wie z.B. Connectoren, Org Relationships oder Empfängerrichtlinien sind noch übrig geblieben

Aus diesen 3x2 Varianten ergeben sich sechs Konfigurationsfälle:

Verzeichnisabgleich Exchange Hybridkonfiguration Beschreibung

Lokaler ADSync ohne Hybrid

Nein

Dies dürfte bis ca. 2022 die Standardinstallation sein, wenn es keinen lokalen Exchange Server gegeben hat, z.B. Migration von einem Fremdsystem.

Lokaler ADSync mit Hybrid

Nein

Variante, wen Sie nach der Installation der Management Tools mit der Schema-Erweiterung im ADSync die Checkbox gesetzt haben oder früher einen vollständigen Hybrid-Mode mit Exchange hatten und die Exchange Hybrid-Bereitstellung zwischenzeitlich komplett zurückgebaut wurde. Die beim Exchange Writeback geschrieben Attribute sind ohne lokalen Exchange Server nicht relevant.

AzureAD Cloud Sync

Nein

Das könnte die zukünftige "neue" Bereitstellung sein, wenn Sie kein Exchange Hybrid brauchen und daher auch den AzureAD Cloud Sync nutzen können.

Lokaler ADSync ohne Hybrid

Konfiguration vorhanden

Diese Konstellation kann nur passieren, wenn Sie Exchange unsauber deinstalliert haben und dann auch noch im ADSync die Checkbox danach entfernt haben.

Lokaler ADSync mit Hybrid

Konfiguration vorhanden

Auch hier ist die DirSync-Hybrid Konfiguration noch vorhanden aber Exchange unsauber entfernt worden.

AzureAD Cloud Sync

Konfiguration vorhanden

Diese Konfiguration war mit installiertem Exchange nur eingeschränkt supportet.

Insofern sind alle sechs Konstellationen funktionstüchtig und wohl von Microsoft auch supportet aber die mit einem "*" gekennzeichneten Fälle können Sie vereinfachen, indem Sie die Checkbox im ADSync Hybrid-Mode entfernen.

Accepted Domain

Die PowerShell der Exchange Management Rolle kennt noch jede Menge weiterer Exchange Commandlets, die aber in einer Umgebung ohne Exchange keine Funktion haben. Sie können einige davon aber natürlich aufrufen und die PowerShell dürfte auch entsprechende Einträge im Active Directory vornehmen. Da sie aber keinen Exchange Server betreiben, sind diese wirkungslos. Das betrifft sicher alle Befehle rund um SMTP-SendConnectoren, Receive Connectoren aber auch Commandlets zu Postfachdatenbanken, ClientAccess-Einstellungen etc.

Aber die Commandlets für Empfänger, d.h. Mailbox, RemoteMailbox, DistributionGroup ,MailContact etc. orientieren sich an den vom Administrator vorgegebenen Empfängerrichtlinien und auch der HCW - Hybrid Configuration Wizard erweitert die Empfängerrichtlinien um die "<tenantname>.mailonmicrosoft.com"-Domain und hinterlegen diese als gültige "RemoteRoutingDomain" für Migrationen. Wie reagiert da nun Enable-RemoteMailbox, wenn es kein lokales Exchange Deployment gibt?

Daher habe ich einen frischen Windows 2019 DC bereitgestellt, auf dem einfach nur die Exchange Management Tools installiert wurden. Natürlich hat das Setup 2,5GB Dateien kopiert und ein "/PrepareSchema" und "/PrepareAD" ausgeführt, so dass eine Exchange Organisation angelegt wurde. Als "Accepted Domain" übernimmt das Setup meine AD-Forest-Domain:

PS C:\> Get-AcceptedDomain | fl

DomainName                       : msxfaq.net
CatchAllRecipientID              :
DomainType                       : Authoritative
MatchSubDomains                  : False
AddressBookEnabled               : True
Default                          : True
EmailOnly                        : False
ExternallyManaged                : False
AuthenticationType               :
LiveIdInstanceType               :
PendingRemoval                   : False
PendingCompletion                : False
FederatedOrganizationLink        :
MailFlowPartner                  :
OutboundOnly                     : False
PendingFederatedAccountNamespace : False
PendingFederatedDomain           : False
IsCoexistenceDomain              : False
PerimeterDuplicateDetected       : False
IsDefaultFederatedDomain         : False
EnableNego2Authentication        : False
InitialDomain                    : False
AdminDisplayName                 :
ExchangeVersion                  : 0.20 (15.0.0.0)
Name                             : msxfaq.net
Identity                         : msxfaq.net
Id                               : msxfaq.net

Diese Konfiguration kann ich natürlich anpassen, wenn meine Office 365-Domain nicht mit der AD-Forest Domain übereinstimmt, z.B. indem ich weitere Domains definiere. Da ich aber keinen Exchange Server habe, findet natürlich kein Routing statt und für die Pflege der Empfänger ist diese Aufgabe auch nicht erforderlich.

Empfängerrichtlinien

Interessant sind hierbei aber die Empfängerrichtlinien, denn diese Einstellungen greifen auch ohne Exchange Server. In meiner Demo-Umgebung wurde dazu folgendes eingestellt. Leere Felder habe ich entfernt:

PS C:\> Get-EmailAddressPolicy | fl

RecipientFilter                   : Alias -ne $null
LdapRecipientFilter               : (mailNickname=*)
RecipientFilterApplied            : True
IncludedRecipients                : AllRecipients
RecipientFilterType               : Precanned
Priority                          : Lowest
EnabledPrimarySMTPAddressTemplate : @msxfaq.net
EnabledEmailAddressTemplates      : {SMTP:@msxfaq.net}
DisabledEmailAddressTemplates     : {}
HasEmailAddressSetting            : True
HasMailboxManagerSetting          : False
NonAuthoritativeDomains           : {}
Name                              : Default Policy
Identity                          : Default Policy
Id                                : Default Policy

Das bedeutet aber, dass jeder Empfänger auch eine Adresse aus dieser Domain bekommt. Ohne GUI ist die Erstellung natürlich etwas kniffliger aber durchaus möglich.

Umstieg von ExServer

Wenn Sie heute noch einen lokalen Exchange Server für da Provisioning nutzen aber der weder Postfächer noch Mailrouting bereitstellt, dann kommt der Wunsche aus, den Server zu entfernen. Das ist auch kein Problem. Ich würde hier wie folgt vorgehen.

  • Bereitstellung eines aktuellen Systems
    Die Exchange Management Rolle kann ich (Stand Mai 2022) auf Windows 10/11 oder Windows Server 2019 oder höher installieren. Sie benötigen daher eine bestehendes oder neues System zur Installation der Management Rolle.
  • Installation und Nutzung
    Es hinder sie niemand daran, die Management Tools parallel zum bestehenden Exchange Server zu installieren und sogar schon zu nutzen. Die Änderungen durch die Management Tools sind kompatibel mit einem lokal installierten Server. Daher können Sie ab jetzt auch mit diesem System die Empfänger verwalten.
  • Rückbau Exchange
    Wenn Sie mit der neuen Verwaltung zurecht kommen, dann können Sie den Exchange Server einfach über das Setup deinstallieren. Dabei wird durch das Setup sowieso geprüft, ob es noch Objekte gibt, die dies verhindern. Exchange Server Deinstallation

So können Sie langsam ihre lokale Installation

Umstieg von "Nichts"

Etwas kniffliger ist der Prozess, wenn Sie aus der anderen Richtung kommen und z.B. bislang ohne ADSync gearbeitet habe. Das machten kleine Firmen oder Startups sehr gerne, die aber irgendwann auch wachsen wollen und vielleicht ein lokales Active Directory nachrüsten. Dann kommt natürlich ADSync in diese neue Umgebung, matched die Objekte und ab dem Moment sperrt die Cloud eine direkte Verwaltung einiger der Exchange Online Eigenschaften auch wenn Sie lokale keinen Exchange Server haben.

In dem Fall müssen Sie die lokalen Objekte nachträglich als "Remote Mailbox" identisch einrichten, damit die Werte wieder in die Cloud übertragen werden.

Siehe dazu auch Exchange Nachprovisioning

Einschätzung

Endlich gibt es einen Weg, Empfänger im lokalen AD allein per PowerShell so zu provisionieren, dass ADSync oder AzureAD Cloud Sync die Informationen zu Exchange Online überträgt, ohne dass es lokal einen Exchange Server geben muss. Unschön ist, dass die Installation der Exchange Management Rolle nicht nur das minimalistische PSSnapin "Microsoft.Exchange.Management.PowerShell.RecipientManagement" installiert, sondern 2,5GB Binaries, die vermutlich nie gebraucht werden und eine rudimentäre Exchange Konfiguration im Active Directory verankert. Es ist dennoch besser als die Installation eines kompletten Exchange Server.

Die Herausforderung an die durchschnittlichen Administratoren bleibt die Verwaltung per Powershell ohne GUI. Aber es gibt schon erste Open Source Programme, die eine GUI auf diese PowerShell aufsetzten.

Weitere Links