Exchange Management Rolle

Schon sehr lange gibt es in Exchange die Möglichkeit, auf einem Client nur die Verwaltungstools zu installieren. Genutzt wurde das bislang aber nur, wenn Sie eine vollwertige Exchange PowerShell mit automatischer Verbindung zu einem Server benötigt haben. Ansonsten können Sie Exchange auf über eine "Remote PowerShell" oder "ECP" verwalten.

Mit dem Exchange 2019CU12 hat Microsoft nicht nur Updates veröffentlicht, sondern auch eine "Management-Rolle" neu eingeführt.

Diese Funktion ist nicht im zeitgleich erschienenen Exchange 2016CU23 enthalten.

Zur Verwaltung von Exchange Online Empfängern mit ADSync aber ohne lokalen Exchange Server ist die Seite Recipient Management PowerShell passend.

Wofür ist das gut?

Das Problem

Die neu eingeführte Rolle soll das Problem von Exchange Online in Verbindung mit ADSync lösen. Sobald Sie Empfänger in Microsoft 365 hosten und die Identitäten aus dem lokalen Active Directory mit ADSync verwalten, können Sie einige Exchange Eigenschaften (z.B. Mailadresse, ProxyAddresses) der synchronisierten Objekte nicht in der Cloud pflegen. Die Lösung dazu war die Installation eines Exchange Servers im lokalen AD, der zwar auch für Mailrouting genutzt werden kann aber speziell kleinere Firmen brauchen und wollen das nicht.

Wenn ich keinen Bedarf für einen lokalen Exchange Server habe, dann möchte ich weder die Hardware (oder VM) dafür bereitstellen und vor allem diese zusätzlichen Systeme nicht immer wieder mit Updates und Patches, Backup, Antivirus und Monitoring versehen müssen. Das sind alles Kosten, die ich mir sparen möchte. Dafür gibt es nun eine Lösung.

Einsatzzweck

Ich kann Sie auf einem Windows 10/11 Client oder Windows 2019/2022 Server installieren und nutzen, ohne einen Exchange Server vor Ort zu haben. Der Einsatzzweck ist schnell schnell erzählt: Mit Exchange Online und ADSync sind die Exchange Empfängereigenschaften in der Cloud immer noch "Readonly" und müssen daher im lokalen AD verwaltet werden. Allerdings brauche ich seit CU12 keinen Exchange Server mit Remote PowerShell oder ECP.

Es ist nun offiziell unterstützt, alleine mit der PowerShell die AD-Properties über die Exchange PowerShell direkt zu verwalten. Das bedeutet aber auch:

  • Kein Exchange Server mehr erforderlich
    Damit entfallen nicht nur die Ressourcen für die Plattform (Hardware oder VM mit Windows, CPU Disk, Ram), sondern auch der Pflegeaufwand und die Absicherung des IIS samt Zertifikate. Allerdings gibt es dann auch keinen Hybrid Connector zwischen dem Tenant, d.h. Mailrouting müssen Sie separat konfigurieren.
  • Exchange 2019 Schema
    Ihr lokales AD muss aber auch ohne Exchange Server natürlich die entsprechenden Schemaerweiterungen erhalten. Die Installation der E2019 CU12 AdminTools erweitert daher das AD-Schema
  • Kein RBAC-Rollen
    Da die lokale Powershell direkt die AD-Objekte und deren AD-Felder verwaltet, muss das ausführende Konto die erforderlichen Rechte haben. Es ist nicht mehr der "Exchange Server Computer", der die Aktionen im Auftrag des Rolleninhabers ausführt. Aber es gibt ein Skript "\Add-PermissionsForEMT.ps1", um die Rechte an eine eigene Gruppe zu delegieren, so dass Sie kein Administrator sein müssen.
  • kein Auditlog
    Entsprechend kann der Exchange Server auch nicht mehr im Eventlog die einzelnen Befehle mitprotokollieren
  • keine ExtensionAgenten
    Auch Erweiterungen auf dem Exchange Server, die beim Aufruf von Exchange Commandlets durch den Rolleninhaber zusätzliche Funktionen ermöglicht haben, gibt es in dem Konstrukt nicht
  • Keine Browseroberfläche
    Ohne IIS oder Exchange Server haben Sie natürlich auch keinerlei GUI per Browser. Jegliche Verwaltung von Exchange Empfängern muss per PowerShell erfolgen.
  • Admin-PC braucht AD-Verbindung
    Damit ist dann auch klar, dass die Verwaltung durch den Admin-PC nur mit einer aktiven Verbindung per LDAP zum Domaincontroller möglich ist. Es gibt keine Remote PowerShell oder HTTP-Transport

Wenn ihnen das alles zu knifflig ist, dann können Sie natürlich problemlos auch weiterhin einen Exchange 2019 Hybrid-Server für das Provisioning installieren. Er kostet seit dem CU12 Update am 20. April 2022 auch keine Lizenz mehr, wenn er keine Postfächer trägt.

Insgeheim hoffe ich ja, dass in Zukunft direkt eine Verwaltung mit dem Exchange Online Admin Center in der Cloud möglich ist. Aktuell müssten Sie dazu aber den DirSync deaktivieren, was andere Nachteile hat. Vielleicht ändert sich hier aber zukünftig ja etwas mit AzureAD Cloud Sync

Exchange Vorgeschichte

Die Verwaltung von Empfängern hat sich über die verschiedenen Exchange Versionen mehrfach geändert. Für das Verständnis und die Auswirkungen ist etwas Geschichtsverständnis hilfreich:

Version Beschreibung

4.0/5.0/5.5

Bis Exchange 5.5 haben Administratoren ihre Empfänger über ein Snapin für Active Directory Benutzer & Computer verwaltet und damit direkt per LDAP ins Active Directory geschrieben.

2000/2003

Mit Exchange 2000 ist zwar da Active Directory weiter der Konfigurationsspeicher, aber die Verwaltung erfolgte dann über die Exchange Verwaltungskonsole. Das Snapin für die "Active Directory Users & Computers"-MMC ist entfallen aber wurde von vielen Administratoren immer noch verwendet.

2007-heute

Mit dem Wechsel auf 64bit und .NET hat Microsoft die Verwaltung an den Exchange Server per PowerShell oder ECP delegiert. Als Administrator habe ich den Exchange Server quasi "beauftragt" für mich die Einstellungen im Active Directory zu setzen. Eine direkte Modifikation der LDAP-Felder ist nicht supported. Seit Exchange 2010 wurde dann auch RBAC umgesetzt, d.h. die Berechtigungen wurden über Rollen gesteuert. Im Idealfall hat ein Admin gar keine Rechte mehr,

2016CU23
2019CU12

Mit diesem Update gibt es nun die Management-Rolle, die auf dem Computer nur die Tools installiert, um die Empfänger zu verwalten. Dazu reicht eine Workstation, d.h. es ist kein Server, der 24h läuft, einen IS-betreibt und besonders abgesichert sein muss. Allerdings schreibt dann der Client direkt ins AD, indem natürlich die Exchange Schema Erweiterung vorhanden sein. Zudem werden die erweiterten Funktionen einer Exchange Remote Powershell umgangen.

  • RBAC-Rechte
  • Logging
  • Auditing
  • Commandlet Agent

Mit 2016/CU23/2019/CU12 öffnet Microsoft also einen Weg, wie ich von einem einfachen Desktop mit den entsprechenden Berechtigungen mit den Exchange Commandlets wieder direkt die Empfänger im Active Directory verwalten kann. Ich brauche keinen Exchange Server aber natürlich Zugriff auf das Active Directory mit den entsprechenden Berechtigungen

Installation

Die Installation erfolgt über die "normale" ISO-Datei die im aktuellen Exchange CU enthalten ist. Der Start des Setup war auch auf meinem deutschen Windows 10 Desktop möglich. Wie bekannt kopiert das Setup ca. 2 GB Installationsquellen temporär auf "C:\WINDOWS\Temp\ExchangeSetup", welche am Ende oder bei Abbruch des Setup wieder weggeräumt werden. Zudem hinterlässt das Setup auch in "C:\ExchangeSetupLogs" die bekannten Protokolldateien ExchangeSetup.log, ExchangeSetupBootStrapper.log und exchangeInstallState.xml. Ein paar Voraussetzungen gibt es zu beachten:

  • Betriebssystem: Windows Server 2019 oder höher
    Eine Installation auf Windows 2016 oder früher ist nicht möglich. Allerdings ist eine Installation auf Windows 10 möglich. Für die Schema-Erweiterung müssen dann aber die AD-RSAT-Tool (wegen LDIFDE) installiert sein.
  • Domain-Mitglied
    Der Client muss zwingend Mitglied eines Active Directory sein.
  • Schema-Erweiterung mit RSAT-ADDS
    Im Forest muss ein aktuelles Exchange Schema vorhanden sein. Ist dies nicht der Fall, dann erweitert das Setup das Schema und braucht dazu die RAST-Tools. Die Organisation wird damit auf
  • "Visual C++ Redistributable for Visual Studio 2012 Update 4" muss installiert sein
    https://www.microsoft.com/en-us/download/details.aspx?id=30679  (ca. 6,9MB)
  • NET 4.8 Framework
    https://support.microsoft.com/kb/4503548
  • IIS6Metabase und IIS Verwaltungskonsole
  • Die Dienste "Remote Registrierung" und "WINMGMT" müssen gestartet sein
  • Speicherplatz >10GB
    Bei mir hat das Setup ca. 3,5 GB installiert und 2 GB temporär angelegt.

Auf meiner Workstation wurde ich bei der Auswahl der Rollen auf die Verwaltungstools beschränkt. Auf einem Server stehen alle drei Rollen zur Auswahl bereit.

Im nächsten Dialog können sie das Zielverzeichnis anpassen. Der Installationsumfang ist mit 2,5GB schon umfangreich, weil Microsoft natürlich viel Logik auf den Client bringen muss, die ansonsten der Server ausführt.

Wenn Sie die folgende Seite sehen, dann arbeiten Sie entweder auf einem System ohne AD-Verbindung oder es gibt in ihrem Forest noch gar keine Exchange Umgebung.

Auf meinem PC im Homeoffice bin ich auf drei Probleme gelaufen. Das kann bei ihnen wieder anders sein.

Auf einem sauberen Domainmitglied ist es aber kein Problem, die Installation durchzuführen. Im Log findet sich dann der Aufruf:

Installing a new product. Package: E:\exchangeserver.msi. Property values: 
DISABLEERRORREPORTING=0 
PRODUCTLANGUAGELCID=1033 
DEFAULTLANGUAGENAME=ENU 
DEFAULTLANGUAGELCID=1033 
INSTALLCOMMENT="Installierte Sprache für dieses Produkt: English (United States)" 
REINSTALLMODE=amus REBOOT=ReallySuppress 
TARGETDIR="C:\Program Files\Microsoft\Exchange Server\V15" 
ADDLOCAL=AdminTools,AdminToolsNonGateway

Danach kommen aber noch Sprachen etc. dazu. Wer, warum auch immer, die Management Rolle automatisch installieren will, sollte das per Setup.exe starten:

<cd>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Role:ManagementTools

Danach befinden sich aber ca. 1,5 GB in 10.000+ Dateien im Programmverzeichnis.

Da ist sicher viel mehr Code drin, als allein für die Verwaltung von Empfänger erforderlich wäre.

Falsche Exchange PowerShell

Im Startmenü findet sich danach die Exchange PowerShell, die sich beim Start mit dem aktuellen Benutzernamen einen Exchange Server sucht und verbindet:

Wenn Sie allerdings keine Exchange Server mehr haben, dann kommen Sie so nicht weiter. Die "Management Tools" enthalten auch keine GUI, da diese normal vom Exchange Server als Webseite angeboten wird.

Richtige Recipient PowerShell

Wenn Sie in einer Umgebung ohne Exchange Server die Empfänger verwalten wollen, was seit Exchange 2019CU12 möglich ist, dann müssen Sie die SnapIns selbst direkt einbinden.

Es muss sogar die klassische PowerShell 2 bis 5 sein und nicht die neue Powershell Core 7

PS C:> Add-PSSnapin  Microsoft.Exchange.Management.PowerShell.RecipientManagement

PS C:> Get-Command -Module Microsoft.Exchange.management.powershell.Recipientmanagement | ft Commandtype,name,version

CommandType Name                           Version
----------- ----                           -------
     Cmdlet Add-DistributionGroupMember    15.0.0.0
     Cmdlet Disable-DistributionGroup      15.0.0.0
     Cmdlet Disable-MailContact            15.0.0.0
     Cmdlet Disable-MailUser               15.0.0.0
     Cmdlet Disable-RemoteMailbox          15.0.0.0
     Cmdlet Enable-DistributionGroup       15.0.0.0
     Cmdlet Enable-MailContact             15.0.0.0
     Cmdlet Enable-MailUser                15.0.0.0
     Cmdlet Enable-RemoteMailbox           15.0.0.0
     Cmdlet Get-AcceptedDomain             15.0.0.0
     Cmdlet Get-Contact                    15.0.0.0
     Cmdlet Get-DistributionGroup          15.0.0.0
     Cmdlet Get-DistributionGroupMember    15.0.0.0
     Cmdlet Get-EmailAddressPolicy         15.0.0.0
     Cmdlet Get-MailContact                15.0.0.0
     Cmdlet Get-MailUser                   15.0.0.0
     Cmdlet Get-RemoteMailbox              15.0.0.0
     Cmdlet Get-User                       15.0.0.0
     Cmdlet Import-RecipientDataProperty   15.0.0.0
     Cmdlet New-AcceptedDomain             15.0.0.0
     Cmdlet New-DistributionGroup          15.0.0.0
     Cmdlet New-EmailAddressPolicy         15.0.0.0
     Cmdlet New-MailContact                15.0.0.0
     Cmdlet New-MailUser                   15.0.0.0
     Cmdlet New-RemoteMailbox              15.0.0.0
     Cmdlet Remove-AcceptedDomain          15.0.0.0
     Cmdlet Remove-DistributionGroup       15.0.0.0
     Cmdlet Remove-DistributionGroupMember 15.0.0.0
     Cmdlet Remove-EmailAddressPolicy      15.0.0.0
     Cmdlet Remove-MailContact             15.0.0.0
     Cmdlet Remove-MailUser                15.0.0.0
     Cmdlet Remove-RemoteMailbox           15.0.0.0
     Cmdlet Set-AcceptedDomain             15.0.0.0
     Cmdlet Set-Contact                    15.0.0.0
     Cmdlet Set-DistributionGroup          15.0.0.0
     Cmdlet Set-EmailAddressPolicy         15.0.0.0
     Cmdlet Set-MailContact                15.0.0.0
     Cmdlet Set-MailUser                   15.0.0.0
     Cmdlet Set-RemoteMailbox              15.0.0.0
     Cmdlet Set-User                       15.0.0.0
     Cmdlet Update-DistributionGroupMember 15.0.0.0
     Cmdlet Update-EmailAddressPolicy      15.0.0.0

Das "RecipientManagement" enthält weder "Enable-Mailbox" noch "Get-Recipient/Update-Recipient" sondern nur die Commandlets zur Verwaltung von Empfänger, die kein Postfach haben.

Das Verfahren selbst ist mir nicht neu und habe ich schon von vielen Jahren auf Exchange PowerShell beschrieben. Nur jetzt gibt es einen offiziellen Weg dies zu installieren und sogar zu nutzen.

Add-PermissionsForEMT.ps1

Wenn Sie keinen Exchange Server haben, dann können sie ihre Konfigurationsaufträge auch nicht an einen Exchange Server senden, der ihre Rollenberechtigung prüft und dann als "Exchange Server" die Berechtigungen zur Änderung an allen Benutzern hat. Sie können natürlich die Exchange Recipient Powershell als Domain Admin aufrufen, aber das ist nicht immer wünschenswert. Microsoft hat aber extra ein PowerShell-Script beigelegt, mit dem Sie als Domain Admin einmalig die erforderlichen Berechtigungen zur Verwaltung der Exchange Eigenschaften delegieren können.

cd "C:\Program Files\Microsoft\Exchange Server\V15\Scripts"
.\Add-PermissionsForEMT.ps1

Das Skript legt eine Gruppe "Recipient Management EMT" an und gewährt dieser die erforderlichen Berechtigungen.

Sie können dann einfach die gewünschten Anwender oder Dienstkonten in diese Gruppe addieren. Die Ausgabe habe ich hier mal für mein Lab dokumentiert.

exchange_management_rolle.htm_add-permissionforemt.txt

Ich gehe aber eher davon aus, dass die größeren Firmen einfach einen Hybrid Connector Server laufen lassen und die Admins bei kleineren Firmen auch weiter als Domain Admin agieren werden.

GUI für PowerShell

Nicht jeder Administrator ist ein täglicher Nutzer der PowerShell und wenn Sie den letzten Exchange Server deinstalliert haben, dann fehlt ihnen auch die WebUI (/ECP), um per Browser die Verwaltung durchzuführen. Aber die Exchange Management Tools können von andere Tools genutzt werden. Es gibt schon die ersten Tools, die eine GUI auf dieser PowerShell aufsetzen.

Exchange Server entfernen

Wenn Sie nur noch Exchange Online nutzen und nun über die Exchange Management Tools ihre Empfänger verwalten wollen, dann können Sie de lokalen Exchange Server natürlich zurückbauen. Das kann bis zur (fast) kompletten Deinstallation der lokalen Instanz führen. Allerdings bleiben zwei Dinge bestehen:

  • Schema Erweiterung
    Die Exchange Schema Erweiterungen des lokalen Active Directory sind weiter erforderlich, damit ADSync etwas lesen kann.
  • Exchange Management Rolle
    Die Verwaltung der durch ADSync in die Cloud repliziert Informationen im lokalen Exchange AD darf laut Microsoft Support Statement nur mit der Exchange PowerShell erfolgen. Direkte Änderungen per ADSIEDIT o.ä. sind nicht gestattet.

Aber das ist immer noch weniger als ein vollwertiger Exchange Server, der SMTP, POP3, IMAP4, HTTP zu erreichen ist und ohne aktuelle Updates und regelmäßige Pflege ein Risiko in ihrem Netzwerk ist. Eventuell brauchen Sie aber dennoch einen Server, z.B. um Mails per SMTP in die Cloud sicher weiterzugeben.

Deinstallation

Wenn Sie die Management-Rolle wieder von dem System entfernen wollen, dann können Sie dies einfach über die "Systemsteuerung" entfernen.

Achtung:
Im Hintergrund deinstalliert das Exchange Setup die einzelnen Komponenten per "Uninstall-MsiPackage". In der Zeit darf keine andere Deinstallation oder Installation erfolgen, da ansonsten das Setup abricht.

Die Aussage im ExchangeServerSetup.log ist eindeutig.

[04.27.2022 10:53:50.0966] [1] [ERROR] Couldn't remove product with code 521e6064-b4b1-4cbc-0c0a-25ad697801fa. 
                                    Es wird bereits anderweitig eine Installation ausgeführt. 
                                    Beenden Sie den anderen Installationsvorgang, bevor Sie diese Installation fortsetzen. Error code is 1618.
[04.27.2022 10:53:50.0966] [1] [ERROR-REFERENCE] Id=LanguagePackUninstallationComponent___73217845dd5e4dd88a658b82846f1c99 
                                      Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
[04.27.2022 10:53:50.0969] [1] Setup is stopping now because of one or more critical errors.

Der Versuch die Deinstallation einfach noch einmal zu starten, lieferte denn aber folgenden Fehler:

[04.27.2022 20:55:43.0136] [0] Setup will run the task 'Start-PreSetup'
[04.27.2022 20:55:43.0136] [1] Setup launched task 'Start-PreSetup -Mode 'Uninstall' -Roles @()'  
[04.27.2022 20:55:43.0144] [1] [ERROR] Unexpected error [0x974F7E7A] while executing command 'Start-PreSetup -Mode 'Uninstall' -Roles @()'.
[04.27.2022 20:55:43.0144] [1] [ERROR] Das Argument kann nicht an den Parameter "Roles" gebunden werden, da es sich um ein leeres Array handelt.
[04.27.2022 20:55:43.0153] [0] [ERROR] Ein Aufrufziel hat einen Ausnahmefehler verursacht.

Zumindest auf meinem PC konnte das Setup danach aber weder über die Systemsteuerung noch per Kommandozeile die Situation wieder alleine lösen. Ich habe dann manuell die einzelnen Pakete gesucht und deinstalliert.

Diese manuelle Schritte entfernen aber keine Eventlog-Einträge, Performancecounter u.a. und sind daher nur etwas für Testumgebungen.

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{{521E60??-B4B1-4CBC-????-25AD697801FA}}" `
   | %{Start-process `
         -nonewwindow `
         -wait `
         -Filepath MsiExec.exe `
         -Argumentlist "/X$($_.pschildname) /qr" `
   }

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{9BBCB564-AAC3-4BF5-????-A4D51A19BF14}" `
   | %{Start-process `
         -nonewwindow `
         -wait `
         -Filepath MsiExec.exe `
         -Argumentlist "/X$($_.pschildname) /qr" `
   }

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{DEDFFB64-42EC-4E26-????-430E86DF378C}" `
   | %{Start-process `
         -nonewwindow `
         -wait `
         -Filepath MsiExec.exe `
         -Argumentlist "/X$($_.pschildname) /qr" `
   }

MsiExec.exe /X{CD981244-E9B8-405A-9026-6AEB9DCEF1F1}

Wie üblich dürfen Sie aber den Inhalt von "C:\ExchangeSetupLogs" und "C:\Windows\Temp\ExchangeServerSetup" manuell bereinigen.

Zukunft

Auf der einen Seite bin ich natürlich froh darüber, dass speziell sehr kleinere Firmen komplett ohne lokalen Exchange Server einen dokumentierten und supporteten Weg zur Pflege der Empfänger in der Cloud haben. Auf der anderen Seite fehlt mir natürlich zumindest eine minimale GUI, die alle Empfänger durchsuchbar anzeigt und editierbar macht. Ich bin aber sicher, dass vielleicht ganz jemand eine passende GUI dazu entwickelt, die im Hintergrund die nun bereitgestellten Commandlets nutzt.

Auf der anderen Seite ist es aus meiner Sicht noch nicht die optimale Lösung. Ich hätte es besser gefunden, wenn ich z.B. in der Cloud direkt die Exchange Eigenschaften im Microsoft  365 Admin Portal oder Exchange Admin Portal (https://admin.exchange.microsoft.com) oder Exchange Online PowerShell nutzen könnte. Microsoft müsste ja nur die entsprechenden Properties entsperren und von der ADSync-Replikation ausschießen. Dann könnten wir auch ohne lokale Schema-Erweiterungen und Installationen arbeiten. Vielleicht geht das irgendwann mal mit AzureAD Cloud Sync

Bis dahin ist die neue Möglichkeiten zumindest für Firmen interessant, die ADSync ohne lokalen Exchange Server nutzen wollen und sich entweder mit der PowerShell gut auskennen oder eine 3rd Party Provisioning-Lösung zum Aufruf nutzen. Diese könnte dann nicht nur die notwendigen Aktionen durchführen sondern dabei auch die Berechtigungen und Prozesse nachbauen, die der Server bislang per RBAC bereitgestellt hat.

Weitere Links