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.

• Manage recipients in Exchange Hybrid environments using Management tools
  https://learn.microsoft.com/en-us/Exchange/manage-hybrid-exchange-recipients-with-management-tools

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.

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.

• ADSync mit Exchange
• 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

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:

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

# Empfänger auflisten

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

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

# 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"}

Disable-RemoteMailbox `
   -identity user1

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

Disable-Distributiongroup `
   -Identity Gruppe1

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/

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:

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
• Manage recipients in Exchange Hybrid environments using Management tools
  https://learn.microsoft.com/en-us/Exchange/manage-hybrid-exchange-recipients-with-management-tools
• 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