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.

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
  • 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.

Regeltätigkeiten

Die Exchange Management Rolle bringt aktuell keinerlei GUI, weder als MMC noch als Snapin für Active Directory Users&Computer 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.

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. Dort müssen Sie dann nur noch eine Exchange Lizenz zuweisen.

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

ADSync: Schema neu einlesen

Sie kennen zwar nun die Standardbefehle zur Verwaltung der Benutzer, aber wenn Sie erst durch die Installation der Exchange Management Tools das AD-Schema erweitert haben, dann sollten Sie ADSync die Change geben, sich auf die neue Umgebung einzustellen.

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.

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