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 StartenAdd-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 aktivierenEnable-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 entfernenDisable-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 deaktivierenEnable-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
- A New Tool to Manage Exchange-related
Attributes Without Exchange Server
https://practical365.com/a-new-tool-to-manage-exchange-related-attributes-without-exchange-server/ - Finally, you can remove your last
Exchange Server
https://practical365.com/removing-the-last-exchange-server/
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.
- Azure AD Connect-Synchronisierung: Mit Azure Active Directory
synchronisierte Attribute
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference-connect-sync-attributes-synchronized
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:- 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 - 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 - AzureAD Cloud Sync
Sie nutzen gar nicht mehr ADSync, sondern direkt den neuen Sync aus der Cloud
- Lokaler ADSync ohne ExHybrid Checkbox
- Exchange Hybrid
Auch wenn Sie keinen Exchange Server mehr betreiben, kann ihre Umgebung zwei Varianten:- Kein Exchange Hybrid
Sie haben mangels Exchange Server nie eine Hybrid-Bereitstellung mittels HCW eingerichtet. - 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
- Kein Exchange Hybrid
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.
- Target Delivery Domain Missing - O365
Migration
https://docs.microsoft.com/en-us/answers/questions/463876/target-delivery-domain-missing-o365-migration.html
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
- ADSync mit Ex Online Only
- LES - Last Exchange Server
- Cloud ProxyAddresses
- Exchange Nachprovisioning
- Ex2016/2019 20.04.2022 Update
- Exchange Management Rolle
- HCW - Hybrid Configuration Wizard
- Exchange Online - Hybrid
- Hybrid Connector Server
- ADSync / AADConnect
- AzureAD Cloud Sync
- msExchRecipientTypeDetails
- msExchRemoteRecipientType
- Exchange Server Deinstallation
-
Exchange Online Provisioning
Gegenüberstellung der verschiedenen Verwaltungskonzepte mit Exchange Online - Exchange Management Rolle - Seit Ex2019CU12 sogar zum Management ohne Exchange Server
- Ex2016/2019 20.04.2022 Update - Das 20. April 2022 Exchange Update fixt viel Probleme aber liefert viel mehr Änderungen
-
Hacking your way around Modern
authentication and the PowerShell modules
for Office 365
https://www.michev.info/Blog/Post/1771/hacking-your-way-around-modern-authentication-and-the-powershell-modules-for-office-365 -
Understanding the Different Versions of
Exchange Online PowerShell Modules and Basic
Auth
https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-the-different-versions-of-exchange-online/ba-p/3394487