Wichtige Info für Exchange Administratoren: Das KB2565063 muss erneut auf alle Exchange Server Versionen installiert werden, die vor Oktober 2018 veröffentlicht wurden. Dies betrifft derzeit alle verfügbaren Exchange Versionen und CUs.

Hintergrund ist, dass die Installationsdateien (Neuinstallation und Updateinstallation) von Exchange eine ungepatchte Version installiert haben und Exchange somit immer noch für eine Remote Code Execution Lücke aus dem Jahr 2011 anfällig ist. Falls das Update also schon einmal installiert war, wurde durch ein Exchange Update wiederum eine ungepatchte Version installiert. Das Update wird nicht automatisch per Windows Update installiert und muss daher manuell installiert werden. Die Installation des Updates erfordert keinen Neustart des Servers oder der Exchange Dienste.

Zukünftige Installationsmedien und CUs werden das KB2565063 als Installationsvoraussetzung angeben. Nähere Informationen gibt es auf dem Exchange Team Blog:

• MS11-025 required on Exchange Server versions released before October 2018

Der Beitrag Exchange Server: Update KB2565063 muss (erneut) installiert werden erschien zuerst auf Frankys Web.

Hier mal ein kurzer Artikel zur Konfiguration der Sophos UTM Email Protection in Verbindung mit einem internen Exchange 2013 / 2016 Server. Diese Einstellungen verwende ich privat, der meiste SPAM wird zuverlässig gefiltert, Viren sind bisher nicht durchgekommen. Die Frage zur Konfiguration der Email Protection kam durch den Artikel “Umstellung von POP Abruf zu MX Record” auf, daher beschreibe ich hier kurz die Konfiguration.

Damit die UTM gültige und existierende EMail Adressen erkennt und Mails an ungültige Empfänger direkt abweisen kann, muss die UTM alle EMail Adressen der Organisation kennen. Seit Exchange 2013 ist dies nur noch zuverlässig durch eine Abfrage gegen das Active Directory möglich. SMTP CallOut Verfahren (in der Sophos Sprache “Serveranfrage”), wird in Verbindung mit Exchange ab Version 2013 immer ein positives Ergebnis liefern. Der Hintergrund ist, dass Exchange die Empfänger erst im Backend prüft, die UTM aber die Anfrage gegen das FrontEnd stellt und an dieser Stelle noch keine Verifizierung des Empfängers stattfindet.

Für die Empfänger Prüfung via Active Directory muss zunächst das AD als Authentifizierungsdienst hinzugefügt werden:

Als Server wird ein Domain Controller angegeben (oder mehrere Domain Controller als Host Gruppe). SSL funktioniert leider seit etlichen UTM Versionen nicht zuverlässig in Verbindung mit der EMail Protection. Als Base-DN wird der DistinguishedName der AD-Domain angegeben:

Jetzt kann die EMail Protection aktiviert werden:

Unter dem Reiter “Routing” werden nun die E-Mail Domänen angegeben, auf die die UTM reagieren soll. Diese müssen mit den akzeptierten Domänen des Exchange Servers übereinstimmen. Die Mails können anhand einer Statischen Hostliste an die Exchange Server zugestellt werden. Für die Empfänger Authentifizierung kann nun das AD verwendet werden:

Die weiteren Einstellungen habe ich in meiner Umgebung konfiguriert, manche sind auch schon im Standard konfiguriert, daher folgen hier nur ein paar Screenshots der Konfiguration:

Mit den Datenschutz Einstellungen muss etwas experimentiert werden. Ich habe zum Beispiel das Versenden von Kontoinformationen blockiert. Einige Regeln sind allerdings zu scharf und blockieren auch valide Mails:

Damit Exchange auch über die UTM verwenden kann, habe ich das Hostbasierte Relay für den Exchange Server erlaubt. Hier würde auch die Möglichkeit “Authentifiziertes Relay” funktionieren:

Damit der Mail Transport verschlüsselt funktioniert, muss die UTM über ein gültiges Zertifikate verfügen, auch die TLS Version lässt sich einstellen. Aktuell funktioniert es bei mir mit “TLS 1.1 oder höher” ganz gut. Nur TLS 1.2 hat bei mir dazu geführt, dass viele Verbindungen wieder unverschlüsselt durchgeführt wurden (Fallback auf Plain SMTP), daher lieber ein bisschen Verschlüsselung als gar keine:

Auch DKIM ist ratsam, die Konfiguration habe ich hier schon einmal beschrieben:

• Sophos UTM und DKIM

Zuletzt kann auch noch der Quarantänebricht aktiviert werden. Benutzer erhalten dann eine Zusammenfassung aller Mails die in der Qurantäne gelandet sind und können diese ggf. freigeben:

Ich habe hier allerdings die Quellnetzwerke eingeschränkt, sodass ein Freigeben der Mails nur aus internen Netzen möglich ist. Welche Freigabeoptionen aktiviert werden, hängt von den Anforderungen ab. Ich würde hier zunächst einmal nur “Spam” aktivieren:

Damit alle Mails zentral über die UTM geroutet werden, kann Exchange mit einem entsprechenden Sendeconnector konfiguriert werden:

Der Beitrag Sophos UTM: Konfiguration der Email Protection für Exchange erschien zuerst auf Frankys Web.

Besser spät als nie: Es wurde heute das CU 11 für Exchange Server 2016 veröffentlicht. Microsoft ist diesmal etwas spät dran, denn eigentlich wurden die Updates bereits im September erwartet.

Durch die späte Veröffentlichung von CU11 wird es im Dezember kein CU geben. CU12 wird somit erst im März 2019 zusammen mit CU1 für Exchange Server 2019 veröffentlicht.

Für Exchange 2013 gibt es kein neues CU, da sich Exchange 2013 wie auch Exchange 2010 im erweiterten Support befinden.

Für Exchange 2010 gibt es allerdings das UR24, welches bereits im September veröffentlicht wurde, daher nehme ich es hier noch mit auf.

• Exchange Server 2016 CU11
• Exchange Server 2010 UR24

Hier geht es zu den Details der Änderungen:

• Exchange Server 2016 CU11
• Exchange Server 2010 UR24

Hier geht es zum Artikel zu den Updates auf dem Exchange Team Blog:

• Exchange Team Blog

Hier findet sich ein Artikel über Punkte die bei der Installation von CUs für Exchange 2016 beachtet werden müssen:

Exchange 2016: Kumulative Updates (CU) installieren

Insbesondere der Windows Defender und andere Virenscanner sollten für die Dauer der Installation deaktiviert werden, diese verursachen gern mal Probleme während der Aktualisierung. Der Windows Defender sorgt insbesondere dafür, das Exchange CUs mehrere Stunden für die Installation benötigen.

Auch die Server Component States sollten nach der Installation eines Updates kontrolliert werden, hier finden sich entsprechende Informationen:

Exchange 2016: Server Component States

Hier findet sich auch noch ein Artikel über mögliche Stolpersteine bei den .NET Framework Abhängigkeiten der CUs für Exchange 2013 und Exchange 2016:

Exchange 2013: Stolperstein beim Update einer alten Version auf das aktuelle CU

Der Beitrag Exchange Server: Neue Updates (Oktober 2018) erschien zuerst auf Frankys Web.

Ein Leser berichtete von einem Problem nach der Installation eines Cumulative Update (CU) auf einem Exchange 2016 Server. Der Aufruf von OWA und ECP war nach der Installation nicht mehr möglich. Beide Anwendungen lieferten nur noch einen Serverfehler.

Beim Aufruf von OWA lautete die Fehlermeldung in etwa so:

Die Datei oder Assembly „Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.“ und OWA „
:-( Da hat etwas nicht geklappt.
Ihre Anforderung konnte nicht abgeschlossen werden. HTTP-Statuscode: 500.
X-ClientId: 69461D0170F742F09942BB1B8E75C0C6
request-id 1a567512-c2b4-4d4e-8f05-5481c5713adf
X-OWA-Error System.Web.HttpUnhandledException
X-OWA-Version 15.1.1531.7
X-FEServer Servername
X-BEServer Servername
Date:12.10.2018 14:56:03
InnerException: System.IO.DirectoryNotFoundException“.

Ähnliches Fehlerbild auch beim Aufruf von ECP:

Die wichtige Meldung hier an dieser Stelle:

Ausnahmedetails: System.IO.FileNotFoundException: Die Datei oder Assembly „Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35“ oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

Die Funktionalität von OWA ließ sich recht schnell mittels dem von Exchange mitgelieferten Scripts “UpdateCas.ps1” wiederherstellen. Das Script lässt sich wie folgt mittels Exchange Management Shell starten:

cd $exinstall
cd .\Scripts\
UpdateCas.ps1

OWA lies sich danach wieder ohne Probleme öffnen, lieferte allerdings immer noch den oben genannten Fehler. Die Ursache waren falsche Pfadangaben in den Anwendungseinstellungen für das Verzeichnis ECP der Exchange Backend Webseite. In diesem Fall war für den Schlüssel “BinSearchFolders” Pfade mit einer nicht existierenden Variabel angegeben.

Wie im folgenden Screenshot zu sehen ist, enthält der Schlüssel “BinSearchFolders” keine absoluten Pfade, sondern Pfade mit der Variable ExchangeInstallDir (%ExchangeInstallDir%):

Die Variable ExchangeInstallDir gibt es allerdings nicht, daher rührt auch die Fehlermeldung System.IO.FileNotFoundException. Damit ECP wieder funktioniert, müssen die entsprechenden Pfade für “BinSearchFolders” angegeben werden:

Die richtigen Pfade können  mit der Exchange Management Shell ermittelt werden. Dazu kann der folgende Befehl verwendet werden:

$folders = "$exinstall" + "bin;" + "$exinstall" + "bin\CmdletExtensionAgents;" + "$exinstall" +"ClientAccess\Owa\bin"
$folders

Der Wert muss nun wie oben beschrieben eingetragen werden. Danach einmal den IIS mittels IISRESET neu starten.

Wie schon erwähnt existiert die Variable ExchangeInstallDir nicht, möglicherweise ist hier beim Update etwas schief gelaufen. Zum Vergleich habe ich andere Exchange 2016 Server überprüft, in allen Installationen waren hier die absoluten Pfade ohne Variablen angegeben. Es gibt allerdings die Variable ExchangeInstallPath, diese ließe sich hier auch verwenden:

Falls OWA oder ECP nach diesen Schritten noch nicht funktionieren, hilft oft die entsprechenden Verzeichnisse neu zu erstellen. Das Vorgehen ist hier beschrieben:

• Exchange 2016: Virtuelle Verzeichnisse im IIS neu erstellen

Der Beitrag Exchange 2016: Serverfehler in Anwendung (OWA und/oder ECP) erschien zuerst auf Frankys Web.

Microsoft hat Exchange Server 2019 freigegeben. Ab sofort können Microsoft Kunden mit Volume License Vertrag die neue Exchange Version runterladen und einsetzen.

Quelle: Exchange Team Blog – Exchange Server 2019 Now Available

Wie bereits angekündigt gibt es Exchange 2019 nur im VL Programm, Kunden ohne Volume Licensing müssen weiterhin Exchange 2016 einsetzen oder zu Office 365 migrieren. Exchange 2019 ist nur noch für große Umgebungen gedacht. Die kleinen Exchange Organisationen mit nur wenigen Postfächern, möchte Microsoft also zukünftig in der Cloud sehen.

Auf dem Exchange Team Blog gibt es eine Übersicht über die neuen Exchange Features:

• Exchange Server 2019 Now Available

Ich werde in der nächsten Zeit weitere Infos und HowTos zu Exchange 2019 veröffentlichen, denn glücklicherweise ist Exchange 2019 auch im Visual Studio Abo enthalten, so kann ich Exchange 2019 im Lab nutzen:

Hier noch eine Zusammenfassung der wichtigsten Exchange Neuerungen:

• Exchange 2019 setzt Windows Server 2019 voraus, empfohlen wird die Installation auf Server 2019 Core
• Support nur noch für TLS 1.2, ältere TLS Versionen werden nicht unterstützt
• Unterstützung von bis zu 48 CPU Cores und 256 GB RAM
• Neue Serach Engine (Bing)
• Suchindex ist nun Bestandteil der Mailbox Datenbank
• MCDB (MetaCache Database, Cache auf SSDs)
• Mehr Kontrolle für Administratoren über Kalendereinträge
• Keine UM Rolle mehr in Exchange 2019 enthalten

Heute wurden ebenfalls weitere Produkte der Office Server Familie freigeben. Die neuen Versionen von Skype for Business, SharePoint und Project Server können ebenfalls ab heute genutzt werden:

• Office 2019 servers available for commercial customers

Office 2019 ist bereits verfügbar, somit ist die Produktfamilie wieder komplett. Soweit bekannt wird die Migration von Exchange 2013 und Exchange 2016 zu Exchange 2019 ebenfalls bereits unterstützt. Artikel zu diesem Themen werden folgen, auch wenn aufgrund der neuen Lizenzierung der Leserkreis wohl kleiner werden wird.

Noch ein kleiner Tipp: Mit Exchange 2016 hatte der Hybrid Configuration Wizard eine “kostenlose” Lizenz für Exchange 2016 Server bereitgestellt, wenn man Exchange im Hybrid Mode betrieben hat. Dies fällt mit Exchange 2019 ebenfalls weg. Der HCW lizenziert für den Hybrid Mode keine Exchange 2019 Server mehr.

Der Beitrag Exchange 2019 ist verfügbar! erschien zuerst auf Frankys Web.

Mit Exchange Server 2016 CU11 haben sich die Voraussetzungen etwas geändert, daher gibt es an dieser Stelle ein aktualisiertes HowTo zur Installation von Exchange 2016 ab CU11 auf Windows Server 2016. Bei diesem HowTo handelt es sich nicht um das Update einer vorhanden Installation, sondern um eine Neu-/Erstinstallation auf Windows Server 2016. Ein HowTo zur Aktualisierung von Exchange Installationen findet sich hier.

Exchange 2016 kann nur auf Windows Server 2016 mit GUI (Desktop Experience) installiert werden. Server 2016 Core und Nano Server werden nicht unterstützt. Das Active Directory Gesamtstrukturfunktionslevel muss mindestens Windows Server 2008 R2 entsprechen. Ältere Funktionslevel werden nicht mehr unterstützt.

Exchange 2016 CU11 unterstützt .NET Framework in der Version 4.7.2. Neuere NET Framework Versionen können Probleme verursachen und sollten daher nicht installiert werden. Hier gilt es die Exchange Support Matrix zu prüfen.

Windows Server 2016 vorbereiten

Vor der Exchange Server Installation sollte temporär Windows Defender abgeschaltet werden. Es kann sonst zu einer längeren Installationszeit und anderen Problemen kommen:

Nach der Exchange Installation kann Windows Defender entsprechend konfiguriert und wieder eingeschaltet werden (siehe unten).

Page File fest einstellen

Die Größe der Auslagerungsdatei sollte fest auf die Größe des Arbeitsspeichers plus 10 MB eingestellt werden. Bei 10 GB RAM (10240 MB + 10 MB) macht das eine feste Größe der Auslagerungsdatei von 10250 MB:

Wenn der Exchange Server über 32 GB oder mehr RAM verfügt, gilt als maximale Größe 32778 MB für die Auslagerungsdatei. Bei 64 GB RAM bleibt es also bei 32778 MB für das Page File.

Hinweis: Exchange Server sollten nicht mehr als 196 GB RAM haben, wird Exchange auf physischen Servern betrieben, sollte HyperThreading deaktiviert werden.

Je nach Umgebung und Storage kann es Sinn machen das Page File auf eine separate Disk zu legen. Wenn das Page File wie oben zu sehen auf Laufwerk C: liegt, sollte C: entsprechend groß dimensioniert sein.

Für die Installation von Exchange empfehle ich eine separate Disk zu verwenden. ob es sich dabei nun um eine separate virtuelle Festplatte oder um ein eigenes Array/JBOD handelt, hängt dabei von der Umgebung ab.

Für virtuelle Exchange Server wäre zum Beispiel ein typisches Setup

• C: VMDK oder VHDX an Controller 1 für das Betriebssystem (~70GB + Page File GB)
• D: VMDK oder VHDX an Controller 1 für Exchange Installation (150 GB)
• E: VMDK oder VHDX an Controller 2 für Datenbanken / Logs

Exchange Voraussetzungen installieren

Exchange benötigt einige Windows Features als Voraussetzung für die Installation, diese können bequem per PowerShell installiert werden:

Install-WindowsFeature NET-WCF-HTTP-Activation45, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

Nach der Installation der Windows Features, muss noch die UCMA Runtime 4 installiert werden:

Unified Communications Managed API 4.0 Runtime

Exchange 2016 CU11 unterstützt .NET Framework 4.7.2, welches noch nicht Bestandsteil der Windows Server GUI Installation ist. NET Framework 4.7.2 kann entweder über Windows Update installiert werden, oder per Offline Installer. Der entsprechende Download findet sich hier:

• Microsoft .NET Framework 4.7.2 (Offlineinstaller)

Neu mit CU11 ist die Voraussetzung der Visual C++ Runtimes, diese beiden müssen ebenfalls installiert werden:

• Visual C++ Redistributable für Visual Studio 2012 Update 4
• Visual C++ Redistributable Packages für Visual Studio 2013

Jetzt sollte noch ein Neustart des Servers erfolgen, dann kann mit der Exchange Installation begonnen werden.

Active Directory Schema Update

Bei größeren Active Directory Umgebungen mit mehreren Standorten und AD-Domänen muss das Schema Update für Exchange manuell ausgeführt werden und die vollständige Replikation abgewartet werden.

In kleinen Umgebungen, mit nur einer Domain und am gleichen Standort, kann in der Regel das Schema Update auch durch das Exchange Setup durchgeführt werden.

Um das Active Directory Schema zu aktualisieren und alle Domänen in der Gesamtstruktur vorzubereiten können die folgenden Befehle verwendet werden (Setup.exe befindet sich im Exchange ISO):

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAD /OrganizationName:"ExchangeOrganisationName" /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms

Nähere Informationen zum Schema Update finden sich hier:

• Prepare Active Directory and domains

Exchange 2016 installieren

Die Installation ist nach der Vorbereitung einfach, daher gibt es an dieser Stelle nur die Screenshots und wenn nötig einen kurzen Kommentar.

Nach Updates muss in der Regel nicht gesucht werden, wenn bereits das aktuelle CU zur Installation benutzt wird:

Ich wähle an dieser Stelle immer “Empfohlene Einstellungen nicht verwenden”, denn so lässt sich der Pfad der Installation und der Name der Organisation festlegen:

Da Exchange 2016 nur noch über die Postfachrolle verfügt (Ausnahme Edge Rolle), muss hier nur die Postfachrolle ausgewählt werden:

Die Installation von Exchange führe ich auf dem Laufwerk D: durch. Somit liegen auch keine Logs, Performance Daten, Queues, etc auf Laufwerk C:

Hier lässt sich nun der Name der Organisation festlegen:

Mit dem eingebauten Schadsoftwarefilter von Exchange habe ich bisher keine guten Erfahrungen gemacht. Ich deaktiviere das Feature daher. Welche Einstellung hier verwendet wird, bleibt jedem selbst überlassen:

In kleinen Umgebungen mit beispielsweise nur einer Active Directory Domain und einem Standort kann Exchange Setup das AD-Schema erweitern. In größeren Umgebungen mit mehren Standorten und/oder mehreren Domänen sollte das Schema Update vor der Installation manuell durchgeführt und die komplette Replikation abgewartet werden:

Das Exchange Setup benötigt dann etwas Geduld, die Installation eines Servers in meiner Testumgebung dauert immer in etwa 45 Minuten

Nach der Exchange Installation

Nach der Installation muss die Grundkonfiguration von Exchange zeitnah erfolgen. Grund hierfür ist, dass Autodiscover bereits per Active Directory SCP angeboten wird. Da Exchange 2016 nach der Installation noch ein selbst signiertes Zertifikat verwendet, kommt es hier unter Umständen zu Zertifikatsfehlern in Outlook.

Exchange Konfiguration abschließen

Die Grundkonfiguration für eine neue Exchange Installation findet sich hier:

• Exchange 2016: Die Basiskonfiguration
• Die HowTos zur Migration von Exchange 2016 finden sich hier:
• Howto: Migration von Exchange 2010 zu Exchange 2016

HowTo: Migration von Exchange 2013 zu Exchange 2016

Windows Defender konfigurieren

Windows Defender ist auf Windows Server 2016 per Default aktiviert. Da Exchange Server einige Ausschlüsse vom Virenscanner benötigt, müssen diese entsprechend auch in Windows Defender hinterlegt werden. Gleiches gilt für Virenscanner anderer Hersteller.

Auf dem Exchange Team Blog findet sich dazu folgender Hinweis:

Windows Defender is on by default in Windows Server 2016. Attention to malware settings is particularly important with Exchange to avoid long processing times during installation and upgrade, as well as unexpected performance issues. The Exchange team recommends the Exchange installation and setup log folders be excluded from scanning in Windows Defender and other Anti-Virus software. Exchange noderunner processes should also be excluded from Windows Defender.

Quelle: Exchange Team Blog

Im Technet sind die Ausschlüsse für Exchange 2016 hier dokumentiert:

• Running Windows antivirus software on Exchange 2016 servers

Die Liste ist allerdings lang, daher hat Exchange MVP Paul Cunningham ein Script veröffentlicht, welches die Ordner, Prozesse und Dateitypen übersichtlich in 3 Dateien einsortiert. Das Script gibt es hier zum Download:

• Generate Antivirus Exclusions for Exchange 2013 and 2016 Servers

Damit nicht alle Ausschlüsse manuell in Windows Defender eintragen werden müssen, habe ich hier ein entsprechendes Script erstellt, welches die Dateien von Paul’s Script benutzt und die Ausschlüsse per PowerShell zu Windows Defender hinzufügt:

• Exchange 2016: Virenscanner Ausschlüsse (Script für Windows Defender)

Nachdem die Ausnahmen eingetragen wurden, kann Windows Defender wieder aktiviert werden.

Leider hat sich der Windows Defender in der Vergangenheit nicht unbedingt mit Ruhm bekleckert. Ich rate daher dazu den Windows Defender zu deinstallieren, wenn ein anderer Virenscanner installiert wird:

• Server 2016: Windows Defender deinstallieren / anpassen

Und bei Fehlern während der Installation?

Während der Installation legt das Exchange Setup sehr detailierte Logs im Verzeichnis “C:\ExchangeSetupLogs” ab. Besonders die Datei “‪C:\ExchangeSetupLogs\ExchangeSetup.log” liefert wertvolle Informationen, wenn die Installation mal schief läuft.

Das Log sollte im Fehlerfall in Ruhe durchgegangen werden. Meistens steht im Log sehr genau, warum das Setup fehlgeschlagen ist. Nach der Behebung des Problems kann das Setup neu gestartet werden. Die Installation wird dann an der Stelle weitergeführt, an der es unterbrochen wurde (sofern das Problem behoben wurde).

Hinweis: Bei virtuellen Servern neigt Mancher gerne dazu im Fehlerfall einfach die VM zu löschen und “noch einmal von vorne zu beginnen”. Dies ist im Falle einer abgebrochenen Exchange Installation eher kontraproduktiv, da Setup in den meisten Fällen bereits Einstellungen im Active Directory vorgenommen hat. Hier müsste man dann erst wieder “Leichen” bereinigen. Es ist also sinnvoller, dass oben angegebene Log zu analysieren und das ursprüngliche Problem zu beheben. In der Regel läuft dann auch das neu gestartete Setup durch.

Der Beitrag HowTo: Installation Exchange 2016 CU11 auf Server 2016 erschien zuerst auf Frankys Web.

Microsoft hat Exchange 2019 veröffentlicht, zum Start gibt es daher hier ein erstes HowTo zur Installation auf Windows Server 2019. Exchange 2019 ist die erste Exchange Version die sich auf Windows Server 2019 Core installieren lässt. Die Installation auf Server Core ist auch die empfohlene Bereitstellungsvariante. Trotz der Empfehlung werden wahrscheinlich viele die Installation von Exchange auf einem Windows Server 2019 mit GUI durchführen. Daher geht es auch in diesem Artikel um die Installation auf Windows Server 2019 mit Desktopdarstellung.

Exchange 2019 wird nur auf Windows Server 2019 unterstützt, daher erübrigen sich HowTos zu anderen Betriebssystemversionen.

Leider hat Microsoft Windows Server 2019 aufgrund von Problemen mit Windows 1809 zurückgezogen. Falls jemand also nicht schon das ISO für Windows Server 2019 runtergeladen hatte, bekommt es derzeit nicht mehr. In diesem Fall kann also nur auf das erneute Release von Windows Server 2019 gewartet werden.

Die Testumgebung

Die Testumgebung ist schnell erklärt, es gibt nur 2 VMs. Einen Domain Controller mit Windows Server 2019 und dem Namen LABDC1, sowie einen installierten Windows Server 2019 mit dem Namen LABEX1 für die Exchange Installation:

Die Domain hört auf den Namen “frankysweblab.de”. LABEX1 verfügt über eine statische IP-Adresse und ist Mitglied der Domain “frankysweblab.de”.

Vorbereitung von Windows Server 2019 für Exchange 2019

Bevor die Exchange 2019 Installation durchgeführt werden kann, müssen zunächst die Voraussetzungen erfüllt werden. Die Exchange 2019 Postfachrolle (neben der Edge Transport Rolle die einzig verbliebene Exchange Rolle), erfordert Visual C++ 2013:

• Visual C++ Redistributable Packages für Visual Studio 2013

Auch UCMA 4 ist weiterhin erforderlich:

Unified Communications Managed API 4.0 Runtime

UCMA 4 findet sich auch im Exchange ISO im Ordner “UCMARedist”.

Exchange Server 2019 setzt .NET Framework 4.7.2 voraus, dieses ist allerdings schon Bestandteil von Windows Server 2019 und muss nicht separat installiert werden.

Sobald die beiden Pakete installiert sind können die Windows Features installiert werden, am einfachsten funktioniert dies via PowerShell:

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS, Server-Media-Foundation

Dies waren auch schon alle Voraussetzungen für Exchange 2019. Der Server sollte jetzt noch einmal neu gestartet werden.

Exchange 2019 Installation

Nachdem die Voraussetzungen für die Exchange Installation geschaffen wurden, kann nun mit der Installation begonnen werden. Das Setup unterscheidet sich nicht kaum von früheren Versionen. Unter Windows Server 2019 mit Desktopdarstellung kann also weiterhin das Exchange 2019 ISO gemountet werden und die grafisch geführte Installation verwendet werden. Im Anschluss finden sich die Screenshots der Installation, an den relevanten Stellen dann auch mit Kommentaren.

Die Suche nach Updates kann übersprungen werden (Ich wüsste auch nicht wann hier mal Updates angezeigt wurden):

An diesem Punkt verwende ich gerne “Empfohlene Einstellungen nicht verwenden”, aber dies ist jedem selbst überlassen:

Exchange 2019 kennt wie auch Exchange 2016 nur noch zwei Installationsmodi: Postfach oder Edge Transport. Die UM-Funktionen wurden in Exchange 2019 entfernt und sind nicht mehr Bestandteil der Postfach Rolle:

Die Exchange Installation sollte nach wie vor auf einem separatem Volume erfolgen, ich nutze daher Laufwerk D: für die Installation:

Die Abfrage nach dem Namen für die Exchange-Organisation erscheint nur wenn es bisher keine Exchange Installation gab. Falls Exchange 2019 in einer bestehenden Exchange Organisation installiert wird, entfällt dieser Dialog und der Name der bestehenden Organisation wird weiter verwendet:

Auch Exchange 2019 verfügt über einen “Schutz vor Schadsoftware”. Dieser eingebaute Schutz sollte allerdings nicht überbewertet werden:

In der geführten Installation bereitet das Exchange Setup das Active Directory auf die Installation von Exchange Server 2019 vor. Die beiden Warnungen sind hier also normal. In größeren Umgebungen sollte das AD Schema manuell vorbereitet werden:

In meiner kleinen Lab Umgebung dauerte die Installation etwa 45 Minuten…

Die initiale Konfiguration von Exchange 2019 ist im nächsten Artikel dran.

Der Beitrag HowTo: Installation von Exchange 2019 auf Server 2019 erschien zuerst auf Frankys Web.

In der Exchange 2019 RTM Version hat sich ein Fehler eingeschlichen, der zu Zertifikatswarnungen trotz gültigen und korrekten Zertifikaten führen kann. Ursache sind falsch konfigurierte Cipher Suites die keine Unterstützung für HTTP/2 enthalten. Dies führt bei manchen Browsern zu Warnungen, wenn beispielsweise auf OWA oder ECP zugegriffen wird. Das Problem tritt nur in der Exchange RTM Version auf und wird mit CU1 für Exchange 2019 behoben.

In meiner Testumgebung konnte ich das Problem bisher nicht nachstellen. Chrome, Edge und Firefox funktionieren mit Zertifikaten meiner Test-Zertifizierungsstelle problemlos, aber das soll ja nichts heißen.

Die meisten Zertifikatswarnungen oder Fehler werden durch falsch konfigurierte Zertifikate oder Hostnamen verursache, wer aber bereits die Exchange RTM Version einsetzt, sollte die TLS Cipher Suites entsprechend konfigurieren. Microsoft hat dazu ein kleines Script veröffentlicht, welches die Arbeit erledigt.

Das Script findet sich hier:

• OWA and ECP unavailable, users get security warning

Das Script kann in der normalen Windows Powershell ausgeführt werden. Ein Neustart der Exchange Dienste ist nicht erforderlich.

Die Exchange RTM Version trägt die Versionsnummer 15.2 (Build 221.12). Neuere Exchange 2019 Versionen sollten diesen Fehler also nicht mehr enthalten.

Die Versionen der Exchange Server lassen sich mit dem folgenden Befehl prüfen:

Get-ExchangeServer | ft name,AdminDisplayVersion

Bis das CU1 für Exchange 2019 veröffentlicht wird, sollte man dieses Problem also im Hinterkopf behalten. CU1 für Exchange 2019 wird voraussichtlich erst im März 2019 veröffentlicht:

Quelle: Released: October 2018 Quarterly Exchange Updates

Der Beitrag Exchange 2019 RTM: Zertifikatswarnungen trotz gültiger Zertifikate erschien zuerst auf Frankys Web.

Nach einem kleinen Howto zur Exchange 2019 Installation folgt nun eine Anleitung zur Erstkonfiguration. Die Basiskonfiguration ist nahezu identisch mit der Konfiguration eines Exchange 2016 Servers. Wer also schon mit Exchange 2013/2016 gearbeitet hat, findet sich hier schnell zurecht.

Wenn Exchange 2019 auf Server 2019 Core installiert wurde, können die hier beschriebenen Schritte der in der Exchange Management Shell direkt auf dem Exchange Server ausgeführt werden. Die Exchange Management Shell lässt sich auf Server Core mit dem Befehl “LaunchEMS” starten.

Für dieses HowTo wurde Exchange 2019 auf einem Windows Server 2019 mit grafischer Benutzeroberfläche installiert, dieses Howto zur Basiskonfiguration gilt aber genauso für eine Installation auf Server Core.

Nach der Installation von Exchange habe ich es mir angewöhnt zuerst die Datenbank umzubenennen und an ihren Bestimmungsort zu verschieben, dies geschieht via Shell mit den folgenden Befehlen:

Get-MailboxDatabase -Server LABEX1 | Set-MailboxDatabase -Name MBXDB01
Move-DatabasePath MBXDB01 -EdbFilePath c:\MBXDB01\MBXDB01.edb -LogFolderPath c:\MBXDB01

Jetzt können die Domänen angegeben werden, für die Exchange zuständig ist. Als akzeptierte Domänen werden alle Domänen angegeben, über die zukünftig E-Mails empfangen oder versendet werden sollen. Für dieses Beispiel habe ich nur die Domain “frankysweb.de” hinzugefügt:

Damit Benutzer automatisch eine entsprechende E-Mail Adresse erhalten, kann eine E-Mail Adressrichtlinie konfiguriert werden. Die Adressrichtlinie kann nach den Vorgaben des Unternehmens erzeugt werden. Für dieses Beispiel habe ich den Alias (entspricht dem Benutzernamen) verwendet:

Nachdem die Adressrichtlinie erstellt wurde, muss die neue Richtlinie noch angewendet werden:

Damit E-Mails ins Internet verschickt werden können, wird ein Sendeconnector benötigt. Es muss mindestens einen Sendeconnector mit dem Adressraum “*” geben, über diesen Connector werden alle Mails versendet, für die Exchange nicht selbst zuständig ist. Für dieses Beispiel lege ich den Sendeconnector “Route-to-Internet” an:

Je nach Umgebung muss der Weg ausgewählt werden, wie Exchange die Mails weiterleiten soll. Dies kann entweder anhand der MX Records der Domänen erfolgen, oder über einen Smarthost (Provider, SPAMFilter, etc):

Hier wird nun der Adressraum des Connectors angegeben. Da dieser Connector alle Mails für die Exchange nicht selbst zuständig ist an einen Smarthost schicken soll, wird hier der Adressraum “*” angegeben:

Im letzten Schritt wird nun noch der (oder die) Exchange Server eingetragen, welche den Connector benutzen:

Der Sendeconnector ist nun angelegt. Zum Schluss müssen noch einmal die Eigenschaften des Connectors geöffnet werden.In den Eigenschaften des Sendeconnectors kann jetzt noch der HELO / EHLO Hostname konfiguriert werden:

Zu guter Letzt folgt noch die Konfiguration der virtuellen Verzeichnisse. Hier werden die URLs festgelegt die von den Clients benutzt werden. Die festgelegten URLs werden auch via Autodiscover direkt an die Clients verteilt. Die virtuellen Verzeichnisse enthalten also die URLs, die von den Clients / Benutzern später für den Zugriff auf Exchange benutzt werden. Alle konfigurierten Hostnamen müssen auch auf dem Zertifikat vorhanden sein, da es sonst zu Zertifikatswarnungen kommt.

Damit alle URLs in einem Schritt identisch konfiguriert werden können, kann das folgende kleine Script benutzt werden. Im Script müssen nur die ersten 4 Zeilen an die eigene Umgebung angepasst werden. Die Empfehlung ist internen ($internalhostname) und externen Hostnamen ($externalhostname) gleich zu lassen.

Den Autodiscover Hostname ($autodiscoverhostname) empfehle ich auf autodiscover.domain.tld zu belassen.

Es würde allerdings auch funktionieren, alle 3 Namen auf dem gleichen Hostname zu konfigurieren. In diesem Fall muss es der Hoster der Domain aber erlauben, dass DNS SRV Einträge gesetzt werden können, dies ist leider nicht immer der Fall.

Hinweis: Alle angegebenen Namen müssen auch für das Zertifikat konfiguriert werden.

Das folgende Script kann nach dem Ändern der ersten 4 Zeilen in der Exchange Management Shell ausgeführt werden:

$servername = "LABEX1"
$internalhostname = "outlook.frankysweblab.de"
$externalhostname = "outlook.frankysweblab.de"
$autodiscoverhostname = "autodiscover.frankysweblab.de"   $owainturl = "https://" + "$internalhostname" + "/owa"
$owaexturl = "https://" + "$externalhostname" + "/owa"
$ecpinturl = "https://" + "$internalhostname" + "/ecp"
$ecpexturl = "https://" + "$externalhostname" + "/ecp"
$ewsinturl = "https://" + "$internalhostname" + "/EWS/Exchange.asmx"
$ewsexturl = "https://" + "$externalhostname" + "/EWS/Exchange.asmx"
$easinturl = "https://" + "$internalhostname" + "/Microsoft-Server-ActiveSync"
$easexturl = "https://" + "$externalhostname" + "/Microsoft-Server-ActiveSync"
$oabinturl = "https://" + "$internalhostname" + "/OAB"
$oabexturl = "https://" + "$externalhostname" + "/OAB"
$mapiinturl = "https://" + "$internalhostname" + "/mapi"
$mapiexturl = "https://" + "$externalhostname" + "/mapi"
$aduri = "https://" + "$autodiscoverhostname" + "/Autodiscover/Autodiscover.xml"   Get-OwaVirtualDirectory -Server $servername | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl -Confirm:$false
Get-EcpVirtualDirectory -server $servername | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl -Confirm:$false
Get-WebServicesVirtualDirectory -server $servername | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl -Confirm:$false
Get-ActiveSyncVirtualDirectory -Server $servername  | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl -Confirm:$false
Get-OabVirtualDirectory -Server $servername | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl -Confirm:$false
Get-MapiVirtualDirectory -Server $servername | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl -Confirm:$false
Get-OutlookAnywhere -Server $servername | Set-OutlookAnywhere -externalhostname $externalhostname -internalhostname $internalhostname -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate'  -Confirm:$false
Get-ClientAccessService $servername | Set-ClientAccessService -AutoDiscoverServiceInternalUri $aduri -Confirm:$false   Get-OwaVirtualDirectory -Server $servername | fl server,externalurl,internalurl
Get-EcpVirtualDirectory -server $servername | fl server,externalurl,internalurl
Get-WebServicesVirtualDirectory -server $servername | fl server,externalurl,internalurl
Get-ActiveSyncVirtualDirectory -Server $servername | fl server,externalurl,internalurl
Get-OabVirtualDirectory -Server $servername | fl server,externalurl,internalurl
Get-MapiVirtualDirectory -Server $servername | fl server,externalurl,internalurl
Get-OutlookAnywhere -Server $servername | fl servername,ExternalHostname,InternalHostname
Get-ClientAccessService $servername | fl name,AutoDiscoverServiceInternalUri

Das Script kann entweder in eine PS1 Datei kopiert werden, oder direkt auf der EMS ausgeführt werden:

Das oben angegebene Script konfiguriert alle virtuellen Verzeichnisse gemäß der Vorgabe. Bei Bedarf lassen sich jetzt die Einstellungen anpassen:

Jetzt muss nur noch das Zertifikat konfiguriert werden. Das Zertifikat wird genauso wie bei Exchange 2013/2016 erstellt. Der Zertifikat muss gemäß dieses Beispiels die Namen “outlook.frankysweb.de” und “autodiscover.frankysweb.de” enthalten. Der Vorgang ist hier ausführlich beschrieben:

• Exchange 2013: Zertifikatsanforderung für öffentliche CA erstellen
• Exchange 2013: SAN Zertifikat und interne Zertifizierungsstelle (CA)

Für die Exchange 2019 RTM Version ist außerdem noch dieser Artikel zu beachten:

• Exchange 2019 RTM: Zertifikatswarnungen trotz gültiger Zertifikate

Für das Thema Exchange Autodiscover habe ich hier ein Whitepaper veröffentlicht, welches auch für Exchange 2019 gilt:

• Exchange 2016: Umfangreiches Whitepaper zu Autodiscover

Der Beitrag Exchange 2019: Die Basiskonfiguration erschien zuerst auf Frankys Web.

Nachdem ich hier schon die Installation von Exchange 2019 auf Server 2019 mit grafischer Oberfläche beschrieben hatte, folgt nun auch die empfohlene Installation auf Windows Server 2019 Core. Die Installation von Exchange 2019 auf Server Core ist schneller erledigt, als auf einem Server mit grafischer Oberfläche, ist Exchange erst einmal installierst, muss man sich so gut wie gar nicht umgewöhnen. Die Exchange Management Shell steht auch auf einem Server Core zur Verfügung. Das Exchange Admin Center kann von einem beliebigen Rechner aufgerufen werden. Wer Exchange auf Server Core installiert und trotzdem nicht auf eine GUI verzichten will, sollte sich das Windows Admin Center anschauen.

Umgebung

Die Umgebung ist wieder denkbar einfach. Es gibt nur einen Domain Controller und eine VM mit Windows Server 2019 Core:

Beide Server wurden als VMs installiert. Die Konfiguration von LABEX2 (Windows Server 2019 Core) ist im folgenden beschrieben.

Vorbereitung Server 2019 Core

Server 2019 Core verfügt über keine GUI und auch die meisten Tools zur Verwaltung (MMC, Servermanager, Explorer, etc) sind nicht enthalten. Kurz um: Nahezu alles was mit der Maus bedient wird, fehlt. Es gibt aber für die grundlegenden Einstellungen wie Hostname, Netzwerk und Updates ein kleines textbasiertes Tool mit dem Namen “sconfig”. Anstatt der GUI also ein TUI (Text User Interface ):

Ich finde es etwas altbacken, dass auch Server 2019 Core nach der Anmeldung erst einmal die alte CMD startet und nicht direkt in die PowerShell wechselt. Sconfig erfüllt aber seinen Zweck: Computername, RDP, Windows Updates, Netzwerk, Domain usw lässt sich in wenigen Schritten konfigurieren:

Ich habe an dieser Stelle nur die Einstellungen vorgenommen:

• Computername
• Beitritt zum Active Directory
• Remote Desktop aktiviert
• statische IP vergeben
• Windows Updates
• Telemetrie… (kein Kommentar…)

All diese Einstellungen lassen sich natürlich auch via PowerShell vornehmen und dadurch automatisieren.

Nachdem die grundlegenden Einstellungen vorgenommen wurden, müssen ein paar Voraussetzungen geschaffen werden.

Exchange Voraussetzungen installieren

Wie jede andere Exchange Version auch, benötigt auch Exchange 2019 auf Server Core ein paar Voraussetzungen. Die lassen sich am schnellsten via PowerShell installieren. Dazu kann direkt aus der CMD die PowerShell ausgerufen werden:

Damit später die UCMA installiert und ggf. das ActiveDirectory Schema manuell aktualisiert werden kann, sind zunächst nur zwei Windows Features erforderlich. Diese können mit dem folgenden Befehl installiert werden:

Install-WindowsFeature Server-Media-Foundation, RSAT-ADDS

Eine weitere Exchange Voraussetzung ist Visual C++ 2013 Runtime. Wer diese bisher direkt per Browser auf dem Server runtergeladen und installiert hat, muss nun auf den Browser verzichten. Aber auch per Powershell lässt sich schnell ein Verzeichnis für den Download anlegen und die Datei runterladen, dazu kann beispielweise das folgende kleine Script verwendet werden:

New-Item c:\install -Type directory
$webClient = New-Object –TypeName System.Net.WebClient
$webClient.DownloadFile('https://download.microsoft.com/download/2/E/6/2E61CFA4-993B-4DD4-91DA-3737CD5CD6E3/vcredist_x64.exe','c:\Install\vcredist_x64.exe')
Get-ChildItem C:\install\vcredist_x64.exe
C:\install\vcredist_x64.exe

Das Script dient nur als Beispiel, auch hier lässt sich die Installation wunderbar automatisieren.

Als Nächstes muss die UCMA 4.0 installiert werden. Bei der Exchange Installation auf Server Core, sollte hier unbedingt die UCMA 4 installiert werden, welche mit dem Exchange ISO mitgeliefert wird. Da ich in meiner Umgebung das ISO direkt als virtuelles Laufwerk der VM gemountet habe, kann ich direkt zu dem Laufwerk wechseln und UCMA installieren:

d:
cd .\UCMARedist\
.\Setup.exe

Hinweis: Wenn das Exchange ISO auf den Server kopiert wurde, lässt sich das ISO auf auf dem Server mounten. Das Mounten von ISO erfolgt mit folgendem Befehl:

Mount-DiskImage c:\Install\ExchangeServer2019-x64_RTM.iso

Das waren auch schon alle Voraussetzungen für die Exchange Installation. Der Rest der erforderlichen Windows Features kann direkt mit dem Exchange Setup installiert werden, dies funktioniert mittlerweile absolut stabil.

An dieser Stelle sollte der Server noch einmal neu gestartet werden, bevor dann mit dem Exchange Setup begonnen wird.

Exchange 2019 installieren

Nach dem Neustart kann Exchange installiert werden, für diese Testumgebung habe ich den folgenden Befehl verwendet:

.\Setup.exe /m:install /roles:mb /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents /OrganizationName:FrankysWebLab

Hinweis: Wenn das ISO auf dem Server gemountet wurde, dann muss es auch nach dem Neustart des Servers noch einmal erneut gemountet werden.

Der Parameter /OrganizationName ist optional und legt nur den Exchange Organisationsnamen fest, wird der Parameter weggelassen, heißt die erste Exchange Organisation “First Exchange Organisation”. Der Parameter sollte nur bei neuen Exchange Installationen angegeben werden in denen es keine früheren Versionen von Exchange Server gibt.

Es gibt noch einige weitere Paramater die direkt beim Setup übergeben werden können. Es lässt sich beispielsweise das Installationsverzeichnis oder Name und Pfad der Datenbank angeben. Eine Liste der Parameter kann mit dem folgenden Befehl ausgegeben werden:

.\Setup.exe /help:Install

Nachdem Exchange installiert wurde, lässt sich mittels EMS die Basiskonfiguration durchführen. Die Exchange Management Shell lässt sich mit dem folgenden Befehl starten (aus CMD sowie PowerShell):

Das Exchange Admin Center lässt sich von einen anderen Rechner unter folgenden Link aufrufen:

• https://ExchangeServerIP/ecp

Der Beitrag HowTo: Installation von Exchange 2019 auf Server 2019 Core erschien zuerst auf Frankys Web.

Seit heute ist Windows Server 2019 wieder verfügbar. Server 2019 wurde ursprünglich schon im Oktober freigegeben, aber kurze Zeit später zusammen mit dem Windows 10 Update wieder zurückgezogen.

Da Windows Server 2019 Voraussetzung für Exchange 2019 ist, konnten hier einige nicht mit der Installation von Testumgebungen beginnen. Nun kann kann Windows Server 2019 runtergeladen und genutzt werden, im VisualStudio Abo ist die neue Version allerdings noch nicht zu finden. Hier ist nach wie vor nur das Language Pack und die Features on Demand Installation verfügbar:

Vermutlich wird hier in Kürze aber auch das aktuelle ISO zum Download angeboten werden. Hier gibt es eine Ankündigung von Microsoft zur erneuten Freigabe:

• Update on Windows Server 2019 availability

Leider enthält der Artikel keine Informationen ob auch Windows Server 2019 von dem Problem der verschwundenen Dateien betroffen war. Im Gegensatz zu Exchange 2019 gibt es für Server 2019 Evaluationsversionen die 180 Tage lang getestet werden können:

• Windows Server 2019 Eval

Da die Frage nach Testversionen zu Exchange 2019 schon gestellt wurde: Es gibt keine Eval Versionen von Exchange 2019. Exchange 2016 kann noch 180 Tage getestet werden, für Exchange 2019 gilt dies nicht. Wer Exchange 2019 installieren möchte, benötigt ein Action Pack, ein Visual Studio Abo oder einen Volumenlizenzvertrag.

Der Beitrag Windows Server 2019 ist (wieder) verfügbar erschien zuerst auf Frankys Web.

Ein Leser fragte mich, ob und wie es möglich ist, einen Link auf der OWA Anmeldeseite hinzuzufügen. In diesem Fall ging es darum einen Link zum Passwort Reset auf der Login Seite hinzuzufügen.

An dieser Stelle sei gesagt, dass es zwar möglich ist, die Login Seite zu verändern, jedoch werden diese Änderungen bei der Installation eines CUs wieder überschrieben. Die Anpassungen müssen also nach jeder Installation eines CUs für Exchange erneut durchgeführt werden. Verständlicherweise werden Änderungen an der Login Seite nicht von Microsoft supported.

Wer trotzdem einen Link zur Login Seite hinzufügen oder das Design anpassen möchte, kann dazu die Datei logon.apsx bearbeiten. Die Datei logon.apsx findet sich im Exchange Installation Ordner unter folgendem Pfad:

• $ExchangeInstallDir\FrontEnd\HttpProxy\owa\auth

Bevor die Datei bearbeitet wird, sollte eine Sicherungskopie erzeugt werden, so lässt sich der Originalzustand schnell wiederherstellen.

In der Datei logon.aspx findet sich eine Zeile “Input name=”isUtf8”…”, durch suchen nach “isUtf8” gelangt man direkt an die entsprechende Stelle. In meinem Fall ist es Zeile 298:

In der nächsten Zeile kann nun ein neuer DIV-Block wie folgt eingefügt werden:

	   <div>
                <img class="imgLnk" 
                    <%if (IsRtl) {%> 
                        src="<%=InlineImage(ThemeFileId.SignInArrowRtl)%>" 
                    <% } %>
                    <% else { %>
                        src="<%=InlineImage(ThemeFileId.SignInArrow)%>" 
                    <% } %>
		  alt=""><span class="signinTxt"><a href="https://passwordreset.microsoftonline.com/">Passwort vergessen?</a></span>
		</div>
        <div class="hidden-submit"><input type="submit" tabindex="-1"/></div> 
      </div>

Wenn jetzt die OWA Anmeldeseite aufgerufen wird, sieht es wie folgt aus:

Mit ein bisschen Arbeit an den CSS Dateien lassen sich hier auch andere Sprachen definieren. In diesem Fall würde auch bei einer englischen Login Seite der deutsche Text angezeigt werden. Wie schon erwähnt werden diese Anpassungen aber mit jedem Exchange CU überschrieben und die Vorgehensweise wird verständlicherweise nicht von Microsoft supported.

Der technisch bessere Weg wäre hier eine eigene Login Seite vorzuschalten, etwa durch einen Reverse Proxy oder Web Application Firewall, diese können dann die Authentifizierung übernehmen und gleichzeitig eine angepasste Version der Login Seite ausliefern.

Tipp: Es lassen sich auch eigene Themes für OWA erstellen, wie das geht, ist hier beschrieben:

Exchange 2016: Eigenes Design für OWA

Der Beitrag Exchange 2016: Link auf OWA Anmeldeseite hinzufügen erschien zuerst auf Frankys Web.

Da nun Exchange 2019 und auch Windows Server 2019 verfügbar sind, steht der Migration von Exchange 2016 zu Exchange 2019 eigentlich nichts mehr im Weg. Nur die geänderte Lizensierung könnte für einige problematisch werden: Exchange 2019 gibt es nur im Volumenlizenzprogramm.

Dies ist der erste Teil der Artikelserie “Migration von Exchange 2016 zu Exchange 2019” und beschreibt die Testumgebung sowie die Installation von Exchange 2019. In den weiteren Artikeln wird dann die Konfiguration von Exchange 2019, das Verschieben der Postfächer, sowie die Deinstallation von Exchange 2016 behandelt.

Eins noch vorweg: Dies ist keine allgemein gültige Migrationsanleitung die sich auf jede Exchange 2016 Organisation anwenden lässt, daher sollte man sich vor der Migration seine Exchange Infrastruktur möglichst 1-zu-1 in einer Testumgebung abbilden um die Migration zu testen.

Die Testumgebung

Die kleine Testumgebung ist recht schnell beschrieben. Es gibt einen Domain Controller auf Windows Server 2016 für das Active Directory frankysweblab.de. Exchange 2016 ist ebenfalls auf Windows Server 2016 installiert. Für Exchange 2019 ist eine VM mit Windows Server 2019 (GUI) vorbereitet:

Hier noch eine Übersicht der Hostnamen und IP Adressen der Testumgebung:

• MIGDC1 192.168.200.16 (Domain Controller)
• Exchange16: 192.168.200.17 (Exchange 2016 Server)
• Exchange19: 192.168.200.18 (nur Server 2019 als Domain Member, Exchange Installation ist Bestandteil dieses HowTos)

Das Active Directory hört auf den Namen frankysweblab.de. Der Zugriff aus dem Internet auf Exchange erfolgt via Portforward. Dies ist zwar nicht optimal, aber ich wollte die Umgebung bewusst einfach halten. Es gibt daher nur eine einzelne NAT Regel auf der Firewall:

Die internen sowie externen Clients stellen die Verbindung zu Exchange mit dem DNS Namen outlook.frankysweblab.de her. Dazu gibt es am internen DNS Server die entsprechenden Einträge:

Auf dem Exchange 2016 Server gibt es zwei Benutzerpostfächer: Frank und Hans, beide Benutzer haben Zugriff auf die Shared Mailbox “Info”, sowie auf 2 Öffentliche Ordner (Kontakte und Termine):

Das Zertifikat für Exchange 2016 stammt von einer internen PKI. Das Zertifikat sowie der Hostname outlook.frankysweblab.de, sollen auch für Exchange 2019 erhalten bleiben.

Soweit zur Konfiguration der Testumgebung.

Installation Exchange 2019

Bevor die Exchange 2019 Installation durchgeführt werden kann, müssen zunächst die Voraussetzungen erfüllt werden. Die erste Voraussetzung ist bereits das Betriebssystem: Exchange 2019 unterstützt nur Windows Server 2019 in der Core oder GUI Variante. Microsoft empfiehlt die Installation auf einem Windows Server 2019 Core. Ich denke aber in der Praxis wird sich häufiger die GUI Variante antreffen lassen, daher installiere ich hier Exchange 2019 auf Server 2019 mit grafischer Oberfläche.

Damit die Exchange Installation durchgeführt werden kann, müssen zunächst Visual C++ und die UCMA Runtime installiert werden:

• Visual C++ Redistributable Packages für Visual Studio 2013

Nach Visual C++ 2013 kann die UCMA Runtime installiert werden:

Unified Communications Managed API 4.0 Runtime

Jetzt können die erforderlichen Windows Features installiert werden, am Einfachsten wird dies per PowerShell erledigt:

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS, Server-Media-Foundation

Nach der Installation der Voraussetzungen sollte der Server einmal neu gestartet werden. Danach kann mit der Exchange Installation begonnen werden:

Die Installation ist nun nahezu selbsterklärend, daher kommentiere ich die Screenshots nur an den relevanten Stellen.

Ich verwende für die Exchange Installation immer die Option “Empfohlene Einstellungen nicht verwenden”, dies gibt etwas mehr Möglichkeiten für die Konfiguration:

Exchange 2019 kennt wie auch Exchange 2016 nur noch zwei Installationsmodi: Postfach oder Edge Transport. Die UM-Funktionen wurden in Exchange 2019 entfernt und sind nicht mehr Bestandteil der Postfach Rolle:

Ich installiere Exchange immer gern auf einem separaten Laufwerk, in diesem Fall Laufwerk D:

Wenn alle Voraussetzungen installiert wurden, gibt es keine Probleme bei der Analyse der Voraussetzungen:

Nachdem die Exchange 2019 Installation abgeschlossen ist, kann mit der Konfiguration begonnen werden. Damit dieser Artikel nicht zu lang wird, ist die Konfiguration Bestandteil von Teil 2 dieses HowTo’s und wird in Kürze folgen.

Der Beitrag HowTo: Migration von Exchange 2016 zu Exchange 2019 (Teil 1) erschien zuerst auf Frankys Web.

Sophos hat die Version 9.6 der UTM veröffentlicht. Das Update auf die Version 9.6 setzt die UTM Version 9.510-5 voraus. Das Update trägt die Version 9.600-5. Hier die Liste der Neuerungen:

What’s new in UTM 9.6?

ATP: New Advanced Threat Protection Library

• Better performance and protection

Certificates: Let’s Encrypt Integration

• Generate and renew Let’s Encrypt certificates from within UTM
• Generated certificates can be used in all UTM components

RED: Unified RED Firmware

• Better 3G/4G Support

Sandstorm: Manual File Submission

• Allows an admin to upload a file for detonation within Sophos Sandstorm
• Files that have not been received via email or web download can also be analyzed with Sophos Sandstorm

Sandstorm: Persistent Reports

• Reporting for Sandstorm Activity over time and with historic information
• Reporting also covering hash lookup based results from Sophos Sandstorm

SMTP Proxy: Enhancements

• Submission Port support in SMTP Proxy
• Configurable Listen Address in SMTP Proxy

WAF: Error Page Customization

• Custom themes for all error pages that are delivered by WAF
• Allows to provide corporate identity on all pages

Quelle: UTM Up2Date 9.600 Released

Das Update kann hier runtergeladen werden:

• http://ftp.astaro.de/UTM/v9/up2date/u2d-sys-9.510005-600005.tgz.gpg

Vor dem Update sollte unbedingt ein Backup erstellt werden und das Update in einer Testumgebung ausführlich getestet werden. Die UTM Updates enthielten schon häufiger Fehler, was zu erhöhter Vorsicht führen sollte.

Die meisten werden auf die Integration von Let’s Encrypt gewartet haben, hierzu werde ich noch ein entsprechendes HowTo veröffentlichen. IKEv2 hat es leider nicht in die Version 9.6 geschafft.

Aktuell wird das Update noch nicht via Up2Date verteilt, es muss daher manuell installiert werden:

Der Beitrag Sophos UTM 9.6 ist verfügbar erschien zuerst auf Frankys Web.

Teil 1 der Artikelserie “Migration von Exchange 2016 zu Exchange 2019” hat nur die Testumgebung und die Installation von Exchange 2019 beschrieben. Jetzt folgen die interessanteren Schritte. In diesem Teil geht es nun um die Konfiguration von Exchange 2019 für die Ko-Existenz mit Exchange 2016.

Ziel dieses Artikels ist es, einen funktionsfähigen Exchange 2019 Server zu haben, welcher später den Exchange 2016 Server ersetzt. Das Zertifikat und auch die URLs (Bsp. OWA) sollen beibehalten werden. Die Benutzer sollen sich also nicht eine neue URL für OWA merken müssen. Auch bestehende Anwendungen die mit Exchange interagieren sollen im besten Fall nichts von der Migration mitbekommen (Kompatibilität vorausgesetzt).

Exchange 2019 Konfiguration

Die erste Konfiguration die ich an einem neuem Exchange Server vornehme, ist das Umbenennen und Verschieben der Datenbank an ihren Bestimmungsort. Per Exchange Management Shell ist dies schnell erledigt:

Get-MailboxDatabase -Server Exchange2019 | Set-MailboxDatabase -Name DB2019
Move-DatabasePath DB2019 -EdbFilePath d:\DB2019\DB2019.edb -LogFolderPath d:\DB2019

Damit Exchange 2019 auch Mails ins Internet zustellen kann, muss der neue Server als Quellserver für den Sendeconnector eingetragen werden:

Hier muss nur der Exchange 2019 Server hinzugefügt werden. Wenn es weitere Sendeconnectoren gibt, dann muss hier ebenfalls der neue Server eingetragen werden:

Als nächstes sind die URLs für die verschiedenen virtuellen Verzeichnisse dran.

Damit nicht jede der Exchange URLs manuell konfiguriert werden muss, kann das folgende kleine Script verwendet werden. Es müssen nur die ersten beiden Zeilen angepasst und die jeweiligen Hostnamen von Exchange 2016 und Exchange 2019 eingetragen werden. Das Script liest dann die URLs aus der Exchange 2016 Konfiguration aus und konfiguriert die gleichen Einstellungen für Exchange 2019:

$Exchange2019Server = "Exchange2019"
$Exchange2016Server = "Exchange16"

#Get URLs from Exchange 2016 Server
$autodiscoverhostname = (Get-ClientAccessService $Exchange2016Server).AutoDiscoverServiceInternalUri
$owainturl = (Get-OwaVirtualDirectory -Server $Exchange2016Server).internalurl
$owaexturl = (Get-OwaVirtualDirectory -Server $Exchange2016Server).externalurl
$ecpinturl = (Get-EcpVirtualDirectory -server $Exchange2016Server).internalurl
$ecpexturl = (Get-EcpVirtualDirectory -server $Exchange2016Server).externalurl
$ewsinturl = (Get-WebServicesVirtualDirectory -Server $Exchange2016Server).internalurl
$ewsexturl = (Get-WebServicesVirtualDirectory -Server $Exchange2016Server).externalurl
$easinturl = (Get-ActiveSyncVirtualDirectory -Server $Exchange2016Server).internalurl
$easexturl = (Get-ActiveSyncVirtualDirectory -Server $Exchange2016Server).externalurl
$oabinturl = (Get-OabVirtualDirectory -server $Exchange2016Server).internalurl
$oabexturl = (Get-OabVirtualDirectory -server $Exchange2016Server).externalurl
$mapiinturl = (Get-MapiVirtualDirectory -server $Exchange2016Server).internalurl
$mapiexturl = (Get-MapiVirtualDirectory -server $Exchange2016Server).externalurl
$OutlAnyInt = (Get-OutlookAnywhere -Server $Exchange2016Server).internalhostname
$OutlAnyExt = (Get-OutlookAnywhere -Server $Exchange2016Server).externalhostname

#Configure Exchange 2019 Server
Get-OwaVirtualDirectory -Server $Exchange2019Server | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl -Confirm:$false
Get-EcpVirtualDirectory -server $Exchange2019Server | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl -Confirm:$false
Get-WebServicesVirtualDirectory -server $Exchange2019Server | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl -Confirm:$false
Get-ActiveSyncVirtualDirectory -Server $Exchange2019Server | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl -Confirm:$false
Get-OabVirtualDirectory -Server $Exchange2019Server | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl -Confirm:$false
Get-MapiVirtualDirectory -Server $Exchange2019Server | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl -Confirm:$false
Get-OutlookAnywhere -Server $Exchange2019Server | Set-OutlookAnywhere -externalhostname $OutlAnyExt -internalhostname $OutlAnyInt -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate' -Confirm:$false
Get-ClientAccessService $Exchange2019Server | Set-ClientAccessService -AutoDiscoverServiceInternalUri $autodiscoverhostname -Confirm:$false

#Display setttings
Get-OwaVirtualDirectory | fl server,externalurl,internalurl
Get-EcpVirtualDirectory | fl server,externalurl,internalurl
Get-WebServicesVirtualDirectory | fl server,externalurl,internalurl
Get-ActiveSyncVirtualDirectory | fl server,externalurl,internalurl
Get-OabVirtualDirectory | fl server,externalurl,internalurl
Get-MapiVirtualDirectory | fl server,externalurl,internalurl
Get-OutlookAnywhere | fl servername,ExternalHostname,InternalHostname
Get-ClientAccessService | fl name,AutoDiscoverServiceInternalUri

Die konfigurierten URLs werden am Ende aufgelistet, diese sollten einmal kontrolliert werden. Beide Server müssen über die gleichen URLs verfügen:

Dies ist eigentlich schon alles.

Zur Sicherheit, sollte man allerdings einmal die komplette Exchange 2016 Konfiguration durchgehen und Exchange 2019 ebenfalls entsprechend konfigurieren. Beispielsweise Einstellungen zu den Empfangs- und Sendeconnectoren (Relay Einstellungen, Drosselung, Nachrichtengröße)

Wichtig sind auch die Einstellungen der Datenbanken, hier sollten ebenfalls die Limits angeglichen werden. Es wäre nicht schön wenn auf dem Exchange 2016 Server beispielsweise 10 GB als Maximum für Postfächer eingestellt wurde, auf Exchange 2019 aber nur 2 GB. Bei der späteren Datenübernahme von Exchange 2016 zu Exchange 2016 wäre somit ein 5 GB Postfach über dem Limit und Exchange verbietet senden und empfangen.

Zertifikat übernehmen

Nach der Konfiguration von Exchange 2019 kann das Zertifikat übernommen werden. Dazu muss zunächst das Zertifikat vom Exchange 2016 Server exportiert werden:

Das Zertifikat wird nun direkt auf dem Exchange 2019 Server gespeichert. An dieser Stelle kann natürlich auch jede andere Freigabe angegeben werden, die von beiden Servern erreicht werden kann. Kennwort und Pfad wird für den Import wieder benötigt:

Jetzt kann das zuvor exportierte Zertifikat auf dem Exchange 2019 Server importiert werden:

Hier muss Pfad und Kennwort des exportierten Zertifikats angegeben werden:

Im letzten Schritt des Dialogs wird noch der Exchange 2019 Server angegeben, auf dem das Zertifikat installiert wird:

Nachdem das Zertifikat installiert wurde, müssen noch die Exchange Dienste an das Zertifikat gebunden werden:

Exchange 2019 ist jetzt in der Lage als Proxy für Exchange 2016 zu arbeiten. Es bietet sich jetzt an ein paar Tests durchzuführen indem die Hosts Datei eines Clients auf bearbeitet wird. In diesem Beispiel würde ich nun also auf einem Client die Hosts Datei anpassen und outlook.frankysweblab.de auf die IP des Exchange 2019 Servers zeigen lassen. Wenn die ersten Tests erfolgreich waren, kann DNS und Firewall umgestellt werden.

DNS und Firewall umstellen

Am internen DNS Server muss nun die IP-Adresse für die Einträge “outlook.frankysweblab.de” und autodiscover.frankysweblab.de” geändert werden. Aktuell verweisen beide Einträge auf die IP des Exchange 2016 Servers:

Die IP der beiden Host-A Einträge wird nun auf die IP des Exchange 2019 Servers geändert. In diesem Fall also 192.168.200.18:

Damit auch externe Clients an Exchange 2019 verwiesen werden, muss noch der NAT Eintrag angepasst werden, aktuell zeigt dieser auf Exchange 2016:

Das Portforward muss an dieser Stelle also nur auf Exchange 2019 geändert werden:

Nach diesen Änderungen ist Exchange 2019 nun CAS-Proxy für Exchange 2016. Die Postfächer der Benutzer werden aktuell immer noch auf Exchange 2016 gehostet. Die Migration der Daten ist Bestandteil des nächsten Artikels, dieser folgt in Kürze.

An dieser Stelle ist es empfehlenswert die DNS Einträge durchzugehen: Weitere DNS Einträge, wie CNAMES und SRV-Records (Autodiscover) sollten ebenfalls auf Exchange 2019 zeigen. In vielen Umgebungen wurden CNAMES auf den Hostname des (alten) Exchange Servers konfiguriert (Beispielsweise für SMTP Traffic von anderen Geräten/Anwendungen). Auch Geräte wie Drucker / Scanner sollten einmal kontrolliert werden, hier wird erfahrungsgemäß gerne die IP verwendet, anstatt eines FQDN.

In dieser Konstellation kann jetzt Exchange 2019 erst einmal parallel zu Exchange 2016 laufen. Wenn sich keine Probleme ergeben, kann mit der Datenmigration weiter gemacht werden. Sollten doch Probleme auftreten, können mit wenig Aufwand die DNS- und NAT Einstellungen rückgängig gemacht werden.

Die Datenmigration ist Bestandteil des nächsten Artikels.

Der Beitrag HowTo: Migration von Exchange 2016 zu Exchange 2019 (Teil 2) erschien zuerst auf Frankys Web.

In Teil 3 der Artikelserie “Migration von Exchange 2016 zu Exchange 2019” ist nun die Migration der Daten dran. Ganz konkret geht es um das Verschieben der verschiedenen Postfächer und öffentlichen Ordner von Exchange 2016 zu Exchange 2019.

Ich verschiebe hier die verschiedenen Postfachtypen einzeln, wenn keine Öffentlichen Ordner oder Shared Mailboxes (Freigaben)eingesetzt werden, können die entsprechenden Punkte natürlich übersprungen werden. Wichtig ist jedoch die Migration der Systempostfächer und natürlich der Benutzerpostfächer.

Wenn es nur wenige Postfächer gibt, können auch alle Postfächer in einem Rutsch migriert werden. Dazu können dann die entsprechenden Befehle einfach nacheinander eingegeben werden. Die im folgenden beschriebenen MoveRequests werden dann entsprechend abgearbeitet.

Migration der Systempostfächer

Bevor die Postfächer der Benutzer und Öffentlichen Ordner verschoben werden, müssen zunächst die Exchange Systempostfächer in die neue Datenbank verschoben werden. Mit dem folgenden Befehl lassen sich die Postfächer der Exchange 2016 Datenbank anzeigen:

get-mailbox -Database DB2016 -Arbitration

Diese Postfächer müssen nun in die Exchange 2019 Datenbank verschoben werden. Dafür kann der folgende Befehl verwendet werden:

get-mailbox -Database DB2016 -Arbitration | New-MoveRequest -TargetDatabase DB2019

Der Status lässt sich mit folgendem Befehl prüfen:

Get-MoveRequest

Nach kurzer Zeit, sollten sich alle MoveRequest im „Status “Completed” befinden:

Da die Systempostfächer nun schon verschoben wurden, können die Moverequests entfernt werden:

Get-MoveRequest | Remove-MoveRequest

Weiter geht es mit den Benutzerpostfächern.

Migration der Benutzerpostfächer

Nachdem die Systempostfächer verschoben wurden, kann mit dem Verschieben der Benutzerpostfächer begonnen werden.

Ich empfehle hier die Trennung zwischen Benutzer- und Shared Mailboxes (auch Raum und Gerätepostfächer). In der Regel gibt es weniger Probleme, wenn Benutzer mit Postfach auf der neueren Exchange Version auf Shared Mailboxes der älteren Exchange Version zugreifen. Daher verschiebe ich die Shared Mailboxes erst nach den Benutzerpostfächern.

Postfächer lassen sich grundsätzlich via Exchange Management Shell und Exchange Admin Center (ECA) verschieben. Ich nutze bisher immer noch das CMDLet “New-MoveRequest” anstelle der Migration Batches, da ich den Eindruck habe, dass die MoveRequest deutlich schneller sind als die Migration Batches (diese werden standardmäßig von der ECA erstellt, können aber auch via Shell erstellt werden). In diesem Beispielen verwende ich die Shell und das CMDLet “New-MoveRequest”, ein weiteres Beispiel für Migration Batches findet sich am Ende des Abschnitts.

Mit dem folgenden Befehl lassen sich alle Benutzerpostfächer in der Exchange 2016 Datenbank anzeigen:

Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox

Wenn nun alle Benutzerpostfächer in einem Rutsch aus der Exchange 2016 Datenbank “DB2016” in die Exchange 2019 Datenbank “DB2019” verschoben werden sollen, kann dazu der folgende Befehl verwendet werden:

Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox | New-MoveRequest -TargetDatabase DB2019

Alternativ lässt sich natürlich auch etwas filtern, sollen beispielsweise nur Benutzerpostfächer aus einer bestimmten OU verschoben werden, kann dazu der folgende Befehl verwendet werden:

Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox | where {$_.OrganizationalUnit -match "frankysweblab.de/FrankysWeb"} | New-MoveRequest -TargetDatabase DB2019

Mittels des WHERE-CMDLets lassen sich hier nahezu beliebige Konstellationen an MoveRequests zusammen stellen.

Wie auch immer die MoveRequests aufgebaut werden, alle Benutzerpostfächer der Exchange 2016 Datenbanken müssen in die Exchange 2019 Datenbanken verschoben werden und dann auch den Status “Completed” aufweisen:

In einer frischen Testumgebung funktioniert das Verschieben meist problemlos, in produktiven Umgebungen gibt es jedoch immer mal wieder fehlerhafte Elemente in den Postfächern. Ohne den Parameter “BadItemLimit” bricht ein MoveRequest beim ersten fehlerhaften Element einfach ab und das Postfach wird nicht verschoben.

Mit dem Parameter “BadItemLimit” lässt sich die Anzahl an tolerierbaren Fehlern festlegen, fehlerhafte Elemente werden dann nicht mit in die neue Datenbank kopiert. Defekte Elemente sind also im Zielpostfach nicht mehr verfügbar und müssen ggf. aus der Datensicherung wiederhergestellt werden. Da aber defekte Elemente ohnehin nicht in die neue Datenbank verschoben werden können, hilft hier meist nur die Angabe des Parameters “BadItemLimit” (Anzahl tolerierbarer Fehler):

Get-Mailbox -Database DB2016 -RecipientTypeDetails UserMailbox | New-MoveRequest -TargetDatabase DB2019 -BadItemLimit 50

Ich habe nun alle Benutzerpostfächer per Shell in die Exchange 2019 Datenbank verschoben, alternativ lasen sich die Postfächer auch per ECA verschieben.

Nachdem die MoveRequests abgeschlossen wurden, können sie gelöscht werden:

Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-MoveRequest

Alternative: Migration Batches via ECA

Postfächer lassen sich auch per Exchange Admin Center (ECA) in die neue Datenbank verschieben. Hier mal ein kleines Beispiel:

Aus der Liste der Postfächer können nun die zu verschiebenden Postfächer ausgewählt werden. Bei vielen Postfächern ist dies natürlich recht mühsam (es ist daher einfacher Migration Batches oder MoveRequests via Shell zu erstellen):

Der neue Migration Batch benötigt einen frei wählbaren Namen und die Zieldatenbank:

Zum Schluss kann noch ausgewählt werden, welcher Benutzer einen Bericht des Migrationbatches erhalten soll. ECA weist schon darauf hin, dass der Migrationbatch nichts für Ungeduldige ist:

Der neue Migration Batch erhält zunächst den Status “Synchronisierung”, hier ist dann Geduld gefragt:

Nach Abschluss wechselt der Migration Batch dann in den Status “Abgeschlossen”:

Sobald der Migration Batch abgeschlossen ist, kann er gelöscht werden.

Migration der Shared Mailboxes (auch Räume und Geräte)

Nachdem die Benutzer Postfächer verschoben wurden, können auch Shared Mailboxes, Raumpostfächer und Gerätepostfächer verschoben werden. Das Vorgehen ist hier fast identisch zu den Benutzerpostfächern. Hier der Befehl zum Anzeigen der entsprechenden Postfächer:

get-mailbox -Database DB2016 -RecipientTypeDetails Shared, Roommailbox, EquipmentMailbox

In diesem Fall ist es nur ein Postfach, auch für dieses Postfach lässt sich nun wieder ein MoveRequest erstellen:

get-mailbox -Database DB2016 -RecipientTypeDetails Shared, Roommailbox, EquipmentMailbox | New-MoveRequest -TargetDatabase DB2019

Wie gehabt lässt sich auch hier wieder bei Bedarf filtern oder die  Postfächer via EAC verschieben, genau wie bei den Benutzerpostfächern.

Auch die MoveRequests für die Shared Mailboxes sollten den Status “Completed” haben, wenn sie erfolgreich verschoben wurden:

Die entsprechenden MoveRequest können nun wieder entfernt werden:

Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-MoveRequest

Weiter geht es mit den Öffentlichen Ordnern.

Migration der Öffentlichen Ordner

Das Gute vorweg, seitdem es keine Öffentliche Ordner Datenbank mehr gibt, sondern mit Exchange 2013 Öffentliche Ordner Postfächer eingeführt wurden, muss keine lästige Replikation der Öffentlichen Ordner mehr eingerichtet werden. Die Postfächer für Öffentliche Ordner lassen sich nun auch ganz einfach per MoveRequest oder Migration Batch verschieben.

Das Vorgehen ist nahezu identisch zu Benutzer- und Shared Mailboxes. Hier der Befehl zum Anzeigen:

get-mailbox -Database DB2016 -PublicFolder

Und hier der Befehl zum Verschieben:

get-mailbox -Database DB2016 -PublicFolder | New-MoveRequest -TargetDatabase DB2019

Auch dieser MoveRequest erhält den Status “Completed” sobald alle Daten migriert wurden:

Sobald dies erfolgreich war, kann auch dieser Request gelöscht werden:

Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-MoveRequest

Jetzt fehlt nur doch die Discovery Search Mailbox.

Migration Discovery Search Mailbox

Auch für die Discovery Search Mailbox ist das Vorgehen nahezu identisch zu den anderen Postfächern, hier wieder der Befehl zum Anzeigen:

get-mailbox -Database DB2016 -RecipientTypeDetails DiscoveryMailbox

Und der Befehl zum Verschieben:

get-mailbox -Database DB2016 -RecipientTypeDetails DiscoveryMailbox | New-MoveRequest -TargetDatabase DB2019

Sobald auch hier der MoveRequest abgeschlossen wurde, kann die Anforderung entfernt werden:

Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-MoveRequest

Jetzt sollten alle Postfächer des Exchange 2016 Servers verschoben sein.

Nachtrag

Das Verschieben der Postfächer lief bei mir natürlich sehr schnell, einfach weil kaum Daten in den Postfächern lagen. Im Normalfall dauert natürlich gerade das Verschieben der Benutzer, Shared und ggf. Öffentlichen Ordner Postfächer recht lange. Dies ist abhängig von den Elementen im Postfach und der Größe des Postfachs. Damit man die Geschwindigkeit ungefähr einschätzen kann, sollten zunächst ein paar große Testmailbox verschoben werden. So lässt sich die Dauer besser abschätzen die insgesamt benötigt wird.

Mit dem folgenden Befehl erhält man auch weitere Statistiken zu den MoveRequests:

Get-MoveRequest | Get-MoveRequestStatistics

Es ist auch nicht weiter ungewöhnlich, dass gerade große Postfächer defekte Elemente enthalten, mittels dem Schalter “-BadItemLimit” lässt sich die tolerierbare Anzahl an defekten Elementen einstellen. Ich würde hier für jeden MoveRequest den Parameter auf 10 Elemente setzen (siehe Abschnitt “Migration der Benutzerpostfächer”). Der Wert lässt sich übrigens auch im Nachhinein noch festlegen, dies ist aber Bestandteil des letzten Teils dieser Artikelserie (folgt in Kürze).

Der Beitrag HowTo: Migration von Exchange 2016 zu Exchange 2019 (Teil 3) erschien zuerst auf Frankys Web.

Die Sophos UTM 9.6 bietet nun auch die lang ersehnte Unterstützung für kostenlose Let’s Encrypt Zertifikate. Zwar unterstützt die UTM nur das ACMEv1 Protokoll und kann somit keine Wildcard Zertifikate anfordern, dafür können aber SAN-Zertifikate mit bis zu 100 DNS-Namen automatisch angefordert werden.

Kurzer Überblick zu Let’s Encrypt

Let’s Encrypt ist eine Zertifizierungsstelle (CA) die mittlerweile von nahezu jedem Gerät als vertrauenswürdig anerkannt wird. Ähnlich wie die bekannten CAs wie beispielsweise Thwate, Digicert und Comodo, akzeptieren also nahezu alle Browser, Clients und Geräte Zertifikate von Let’s Encrypt und zeigen keine Zertifikatswarnung wie “Diese Webseite ist unsicher” an.

Let’s Encrypt Zertifikate sind im Gegensatz zu den Zertifikaten anderer CAs kostenlos und können nahezu vollautomatisch angefordert und ausgestellt werden. Gerade SAN-Zertifikate mit mehreren Domain- und Hostnamen können bei den “alten Hasen” der CAs recht teuer werden. Zwar sind die Preise für Standard Zertifikate schon deutlich gesunken, allerdings zahlt man bei Thawte für ein domainvalidiertes SAN Zertifikat mit 2 Jahren Laufzeit immer noch 129 EUR. Zertifikate von anderen CA sind teilweise noch deutlich teurer.

Let’s Encrypt stellt ebenfalls domainvalidierte Zertifikate aus, allerdings immer nur mit einer Laufzeit von 3 Monaten. Wer also nicht manuell alle 3 Monate Zertifikate an Webservern und anderen Hosts tauschen möchte, muss sich hier Gedanken um die Automatisierung machen. Let’s Encrypt bietet dazu das Protokoll ACME (ja, es heißt wirklich so) an. Mit entsprechenden Clients die für nahezu jede Plattform zur Verfügung stehen, lassen sich automatisch Zertifikate anfordern und vor Ablauf erneuern. Die geringe Gültigkeit von 3 Monaten ist somit also auch kaum ein Problem. Mit der dem ACMEv2 Protokoll können sogar Wildcard Zertifikate angefordert werden. Hierfür ist allerdings eine Validierung via DNS nötig, dies macht die Automatisierung schwieriger. Zertifikate die mit dem ACMEv1 Protokoll angefordert werden, unterstützen neben der DNS Validierung auch die HTTP Validierung, dies lässt sich besonders gut automatisieren.

Let’s Encrypt stellt nur domainvalidierte Zertifikate aus, es muss also lediglich nachgewiesen werden, dass der Anforderer des Zertifikats Zugriff auf die entsprechende Domain hat. Extended Validation Zertifikate (grüner Balken im Browser) können nicht via Let’s Encrypt angefordert werden.

Let’s Encrypt bietet aktuell nur “Webserver” Zertifikate an, andere Zertifikatstypen wie S/MIME oder Code Signing Zertifikate können nicht angefordert werden.

Für alle Arten von Webservices lassen sich Let’s Encrypt Zertifikate allerdings wunderbar verwenden. Bevor irgendein Dienst im Internet per Plain-HTTP veröffentlicht wird (Mail, Extranet, Intranet, Benutzerportal, usw.), kann also mit wenig Aufwand und Kosten auch eine TLS-Verschlüsselte Kommunikation mittels Let’s Encrypt Zertifikate umgesetzt werden.

Sophos UTM 9.6 und Let’s Encrypt

Hinweis: Wie bei jeder anderen öffentlichen CA mit Domain Validierung auch, können keine Zertifikate mit nicht öffentlich auflösbaren DNS-Namen ausgestellt werden (Bsp. utm.frankysweb.local, hostxy.frankysweb.intern, etc). Wenn die UTM via ACMEv1 ein Zertifikat anfordert, validiert Let’s Encrypt die Domains via HTTP. Daher muss Let’s Encrypt alle konfigurierten Domain Namen via DNS auflösen und per Port 80 (http) erreichen können.

Let’s Encrypt lässt sich sehr einfach auf der UTM 9.6 konfigurieren. Wie schon erwähnt lassen sich allerdings nur SAN-Zertifikate anfordern. Wildcard Zertifikate lassen sich aufgrund der fehlenden ACMEv2 Unterstützung nicht anfordern.

Damit automatisch Let’s Encrypt Zertifikate angefordert und auch erneuert werden können, muss zunächst einmal die Einstellung “Let’s Encrypt Zertifikate zulassen” aktiviert werden:

Nachdem Let’s Encrypt aktiviert wurde, kann nun ein Zertifikat angefordert werden.

Für das neue Zertifikat muss ein Name angegeben und die Methode “Let’s Encrypt” ausgewählt werden. Der Punkt “Schnittstelle” ist in diesem Fall wichtig, hier muss die Schnittstelle angegeben werden, unter der die angegeben Domänen per Port 80 erreichbar sind. Alle angegebenen Domänen müssen im DNS auflösbar sein und via Port 80 aus dem Internet erreichbar sein. In der Regel handelt es sich hier also um externe Schnittstelle (WAN). Wenn mehrere externe WAN Schnittstellen zum Einsatz kommen, müssen in diesem Fall auch mehrere Zertifikate angefordert werden. Dies kann zum Beispiel der Fall sein, wenn das UTM Userportal unter WAN IP1 und die Webprotection via WAN IP2 erreichbar ist.

Im Feld “Domänen” müssen nun alle Hostnamen angegeben werden, die das Zertifikat enthalten soll:

Nachdem die Zertifikatsanforderung gespeichert wurde, kann im neuen Live Log “Let’s Encrypt” der Status kontrolliert werden:

Das Log ist auch sehr hilfreich bei der Fehlersuche, in meinem Fall wurde das Zertifikat erfolgreich ausgestellt:

Wenn das Zertifikat erfolgreich angefordert und ausgestellt wurde, wird das Zertifikat mit einem kleinen grünem Symbol versehen:

Bis hierher wurde das Zertifikat nur ausgestellt, es muss nun auch noch den angedachten Diensten zugeordnet werden. Das neue Zertifikat lässt sich nun also Beispielweise für das Admin Portal nutzen:

Das Zertifikat lässt sich natürlich auch für alle weiteren Dienste nutzen, wie zum Beispiel die Email Protection:

Hier noch ein Beispiel zur Nutzung des Zertifikats und der Webserver Protection:

Das Zertifikat ist 3 Monate lang gültig. den Austausch nimmt die UTM vor Ablauf automatisch vor. Eine erneute Zuweisung des Zertifikats an die verschiedenen Dienste ist dann nicht mehr nötig. Ob dies auch funktioniert, kann ich allerdings erst in 3 Monaten sagen.

Alternative für Wildcard Zertifikate

Let’s Encrypt bietet Clients für nahezu alle Betriebssysteme an, mit dem ACMEv1 Protokoll und der HTTP Validierung lassen sich die Zertifikate super automatisieren.

Für Wildcard Zertifikate ist allerdings das ACMEv2 Protokoll und damit auch die DNS-Validierung erforderlich. In den meisten Fällen erfordert die DNS-Validierung allerdings etwas manuellen Aufwand, denn der TXT-Record für die Validierung muss beim Hoster der Domain konfiguriert werden. Da die wenigsten Hoster keine API für ihre DNS-Server bereitstellen oder entsprechende Protokolle unterstützen, muss der TXT-Record in der Regel manuell angelegt und aktualisiert werden.

Die Webseite SSLforFree stellt ein Webinterface zur Verfügung welche die Zertifikate via Let’s Encrypt anfordert und die nötigen Einstellungen zu den Validierungsmöglichkeiten anzeigt:

• SSLforFree

Mit der Webseite SSLforFree lässt sich also Let’s Encrypt wie jede andere kommerzielle CA auch nutzen. Die Zertifikatslaufzeit beträgt allerdings weiterhin 3 Monate, bei nur wenigen Zertifikaten ist der Aufwand aber sicherlich zu vernachlässigen.

Der Beitrag Sophos UTM 9.6: Kostenlose Let’s Encrypt Zertifikate erschien zuerst auf Frankys Web.

Im letzten Teil der Artikelserie “Migration von Exchange 2016 zu Exchange 2019” wird die Deinstallation von Exchange 2016 vorbereitet und die Migration abgeschlossen.

Der kleine Abschnitt Troubleshooting widmet sich der häufigsten Ursache für fehlgeschlagene oder angehaltene MoveRequests. Bei Migrationen kann es immer wieder zu Problemen kommen, welche man vorher nicht ausschließen konnte. Die Ursachen können vielfältig sein, daher kann ich hier nicht auf alle Eventualitäten eingehen.

Troubleshooting

Bevor Exchange 2016 deinstalliert werden kann, müssen alle Postfächer aus der Exchange 2016 Datenbank in die Exchange 2019 Datenbank verschoben werden. In Teil 3 dieser Artikelserie wurden dazu MoveRequests verwendet.

Es kommt aber durchaus häufig vor, dass manche MoveRequests den Status “Suspended” oder “Failed” aufweisen und dadurch das Postfach nicht verschoben wird.

Der Status der MoveRequests lässt sich mit dem folgenden Befehl prüfen:

Get-MoveRequest

In den meisten Fällen werden die MoveRequests nicht abgeschlossen, da es defekte Elemente innerhalb der Postfächer gibt. Hier hilft es meist schon das entsprechende Limit der tolerierbaren Fehler anzuheben. Mit dem folgenden Befehl, können für vorhandene MoveRequests 50 fehlerhafte Elemente zugelassen werden:

Get-MoveRequest | Set-MoveRequest -BadItemLimit 50

Die MoveRequests lassen sich dann fortführen:

Get-MoveRequest | Resume-MoveRequest

Wie bereits erwähnt kann es auch andere Ursachen für fehlerhafte Verschiebungsanforderungen geben. Mit dem folgenden Befehl erhält man weitere Informationen für das Troubleshooting:

Get-MoveRequest | Get-MoveRequestStatistics | fl

Hier gibt es auch einen weiteren Artikel der fehlgeschlagenen MoveRequests helfen kann:

• Managing failed mailbox move requests

Wie schon eingangs erwähnt, gibt es viele Ursachen für fehlgeschlagene MoveRequests. Weitere Ursachen und Lösungen können gerne als Kommentar hinterlassen werden. Falls genügend Tipps zusammenkommen, kann ich diese gerne als separaten Artikel aufnehmen.

Wenn alle MoveRequests erfolgreich abgeschlossen wurden und den Status “Completed” aufweisen, können die MoveRequests gelöscht werden:

Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest

Damit bei der Deinstallation möglichst keine Probleme auftreten, sollte noch etwas aufgeräumt werden.

Aufräumen und Deinstallation vorbereiten

Damit die Deinstallation von Exchange 2016 möglichst ohne Probleme verläuft, sollten vor der Deinstallation noch ein paar Aufräumarbeiten erledigt werden.

Bei meinen Aufräumarbeiten ist mir zum Beispiel noch aufgefallen, dass ich vergessen hatte die AuditLog Mailbox zu verschieben. Dies hatte ich in Teil 3 nicht durchgeführt, daher reiche ich es jetzt nach. Hier die schon bekannten Befehle zum Anzeigen und Verschieben:

get-mailbox -Database DB2016 -AuditLog
get-mailbox -Database DB2016 -AuditLog | New-MoveRequest -TargetDatabase DB2019
Get-MoveRequest
Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest

Nachdem auch das AuditLog Postfach verschoben wurde, sollten nun keine Postfächer mehr in der alten Exchange 2016 Datenbank gespeichert sein. Mit den folgenden Befehlen lassen sich die gängigen Postfachtypen abfragen:

get-mailbox -Database DB2016
get-mailbox -Database DB2016 -Arbitration
get-mailbox -Database DB2016 -Archive
get-mailbox -Database DB2016 -PublicFolder
get-mailbox -Database DB2016 -AuditLog

Ebenfalls sollte es nun keine MoveRequests mehr geben. Sollte es an dieser Stelle noch MoveRequests geben, müssen diese zunächst abgeschlossen und gelöscht werden (Siehe Abschnitt Troubleshooting). Mit dem folgenden Befehl lässt sich prüfen, ob es noch Moverequests existieren:

Get-MoveRequest

Wenn keine Postfächer mehr in der Exchange 2016 Datenbank vorhanden sind und auch keine MoveRequests mehr angezeigt werden, kann der Exchange 2016 Server aus der Bereichsdefinition des Sendeconnectors entfernt werden:

Bei der Deinstallation sollte es nun zu keinen Problemen kommen.

Deinstallation

Die Deinstallation von Exchange 2016 kann über die Systemsteuerung via “Programme und Features” gestartet werden:

Hinweis: Bevor Exchange 2016 deinstalliert wird, sollte möglicherweise vorhandene AntiViren/AntiSPAM Software für Exchange deinstalliert werden. Oft verhindern diese Programme eine erfolgreiche Deinstallation von Exchange.

Die Deinstallationsroutine überprüft nach dem Klick auf “Weiter” noch einmal ob die Deinstallation durchgeführt werden kann:

In diesem Fall ist alles in Ordnung und die Deinstallation kann gestartet werden:

Die Deinstallation dauert ein paar Minuten:

Exchange 2016 wurde erfolgreich deinstalliert und es wird ein letzter Neustart angefordert:

Somit ist die Migration zu Exchange 2019 abgeschlossen. Optional gibt es noch zwei weitere Steps die nun ausgeführt werden können.

Optional: Server aus Domain entfernen

Sofern der Exchange 2016 Server keine weiteren Dienste mehr ausführt, kann nun der Server aus dem AD entfernt und runtergefahren werden. Die Windows Installation sollte nicht für andere Dienste weiter verwendet werden. Auch das Computerkonto des alten Exchange 2016 Server sollte gelöscht werden (wenn noch vorhanden).

Hinweis: Die Deinstallationsroutine entfernt nicht die alten Datenbank Dateien und Logs, falls das Betriebssystem des alten Exchange Servers also noch etwas in Betrieb bleibt (möglicherweise aufgrund anderer Dienste), dann sollten Datenbank und Logs manuell gelöscht werden:

Wenn die Serverhardware weiter verwendet werden soll, dann bietet sich hier eine saubere Neuinstallation des Betriebssystems an.

Optional: Client Access Rules (Exchange Admin Center einschränken)

Die “Client Access Rules” sind ein neues Exchange 2019 Feature, welches unter anderem dazu benutzt werden kann, den Zugriff auf das Exchange Admin Center (EAC) einzuschränken.

In der hier beschriebenen Testumgebung gibt es einen NAT Eintrag welcher Port 443 auf den Exchange 2019 Server weiterleitet:

Dieser NAT Eintrag veröffentlicht Exchange 2019 im Internet, somit sind Protokolle wie ActiveSync und MAPIoverHTTP aus dem Internet nutzbar. Gleichzeitig wird damit aber auch das Exchange Admin Center (EAC) aus dem Internet erreichbar gemacht. Administrative Oberflächen, wie EAC, die direkt im Internet erreichbar sind, stellen immer ein potenzielles Sicherheitsrisiko dar. Gerade wenn, wie hier in dieser Testumgebung, keine Web Application Firewall oder andere Schutzmaßnahmen zum Einsatz kommen.

Damit administrative Oberflächen wie das EAC nicht direkt aus dem Internet aufgerufen werden können, lässt sich der Zugriff eingrenzen, beispielsweise auf das interne Netzwerk oder ein dediziertes Management Netz.

Mit den folgenden Befehlen lässt sich beispielsweise der Zugriff auf die RemotePowerShell und EAC auf das interne Netzwerk 192.168.200.0/24  einschränken:

New-ClientAccessRule -Name "Block Remote PowerShell" -Action DenyAccess -AnyOfProtocols RemotePowerShell -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24
New-ClientAccessRule -Name "Block Remote ExchangeAdminCenter" -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24

Der Zugriff von Rechnern außerhalb des Subnetzes 192.168.200.0/24 auf EAC und PowerShell ist somit nicht mehr möglich. Hier muss natürlich etwas aufgepasst werden, damit man sich nicht selbst aussperrt.

Ein ausführlicher Beitrag zu den Client Access Rules folgt noch.

Der Beitrag HowTo: Migration von Exchange 2016 zu Exchange 2019 (Teil 4) erschien zuerst auf Frankys Web.

Die Migration von Exchange 2016 zu Exchange 2019 habe ich auf vier Artikel aufgeteilt. Damit die Artikel einfacher zu finden sind, hier einmal die Links in der entsprechenden Reihenfolge:

• HowTo: Migration von Exchange 2016 zu Exchange 2019 (Teil 1)
• HowTo: Migration von Exchange 2016 zu Exchange 2019 (Teil 2)
• HowTo: Migration von Exchange 2016 zu Exchange 2019 (Teil 3)
• HowTo: Migration von Exchange 2016 zu Exchange 2019 (Teil 4)

Mein kleines Fazit zur Migration

Die Migration der Testumgebung verlief absolut problemlos. Da die Migration der Öffentlichen Ordner auch kein Problem mehr darstellt, sondern in der Regel nur noch die Postfächer verschoben werden müssen, ist die Migration ziemlich schnell erledigt. Im Prinzip muss nur der neue Exchange Server installiert und konfiguriert werden. Dann folgt auch schon das Verschieben der Postfächer. Auch die Migration von Exchange 2013 zu Exchange 2019 ist ebenso schmerzlos möglich.

Meine Testumgebung lief hier übrigens mit nur 16 GB RAM für den Exchange 2019 Server. Dies ist also weit entfernt von den “empfohlenen” 128 GB RAM für Exchange 2019, einen Nachteil bei den wenigen Postfächern konnte ich nicht feststellen. Kleine Umgebungen werden also auch mit weniger RAM auskommen, obwohl dies von Microsoft so wohl nicht vorgesehen ist. Microsoft möchte Exchange 2019 nur noch im Enterprise Segment platzieren, und auch da nur für die großen Unternehmen die “noch nicht” bereit sind für Office 365 / Exchange Online.

Meine Meinung

Meiner Meinung nach gibt es aktuell für kleine und mittlere Unternehmen gar keinen Grund von Exchange 2016 zu Exchange 2019 zu migrieren. Die neuen Features sind für die meisten Unternehmen fast zu vernachlässigen und Exchange 2016 wird noch ein paar Jahre unterstützt. Wer also Exchange 2016 einsetzt, kann sich ja einmal die neuen Features anschauen und bewerten ob eine Migration lohnenswert ist. Für die Benutzer ändert sich mit der neuen Exchange Version ohnehin nicht viel.

Der Beitrag Migration Exchange 2016 zu Exchange 2019 erschien zuerst auf Frankys Web.

Eines der neuen Exchange 2019 Features sind die “Client Access Rules”. Client Access Rules können verwendetet werden um den Zugriff auf Exchange Server anhand von gewissen Kriterien einzuschränken. Ein Anwendungsfall wäre zum Beispiel, den Zugriff auf das EAC nur aus einem Management Netzwerk zu erlauben.

Leider sind die Client Access Rules in der Exchange 2019 RTM Version noch nicht vollständig implementiert, derzeit lassen sich nur RemotePowerShell und ExchangeAdminCenter mit Client Access Rules verwalten. POP3, IMAP, ActiveSync, OWA usw. lassen sich derzeit noch nicht mit Client Access Rules einschränken. Ich hoffe, dass mit den nächsten CUs für Exchange 2019 die Client Access Rules noch erweitert werden, damit sich auch andere Protokolle verwalten lassen und der Zugriff granularer gesteuert werden kann.

Übersicht der Befehle

Die Client Access Rules lassen sich nicht via EAC verwalten, sondern ausschließlich via PowerShell. Für die Verwaltung der Client Access Rules gibt es 5 CMDLets:

• Get-ClientAccessRule (Anzeigen der Regeln)
• New-ClientAccessRule (Neue Client Access Rule hinzufügen)
• Remove-ClientAccessRule (Regel löschen)
• Set-ClientAccessRule (Anpassen einer vorhandenen Regel)
• Test-ClientAccessRule (Test einer Client Access Rule)

Wie bereits erwähnt lassen sich derzeit nur RemotePowerShell und ExchangeAdminCenter mit Client Access Rules verwalten. Der Versuch andere Protokolle bzw. Schnittstellen zu verwalten schlägt mit Exchange 2019 RTM fehl:

Eine detaillierte Beschreibung der Befehle findet sich hier:

• Get-ClientAccessRule
• New-ClientAccessRule
• Remove-ClientAccessRule
• Set-ClientAccessRule
• Test-ClientAccessRule

Allerdings sind nicht alle der in den Artikeln beschriebenen Einstellungen in Exchange 2019 RTM verfügbar.

Wie funktionieren Client Access Rules

Client Access Rules funktionieren ähnlich wie Exchange Transport Regeln bzw. Firewall Regeln. Die Regel mit der höchsten Priorität (niedrigste Zahl) wird zuerst angewendet, nachdem eine zutreffende Regel angewendet wurde, werden keine weiteren Regeln mehr verarbeitet.

Die Priorität gibt also Reihenfolge vor, in der die Regeln abgearbeitet werden, die Priorität beginnt immer mit 1, alle weiteren Regeln folgen darauf (2, 3, 4, etc.). Es ist nicht möglich eine Regel mit Prio 1 und eine Regel mit Prio 5 zu erstellen. In diesem Fall wird die zweite Regel automatisch die Prio 2 bekommen. Ähnlich verhält es sich wenn eine Regel gelöscht wird. Wenn die Regel mit Prio 1 gelöscht wird, rücken die restlichen Regeln auf, die Regel mit Prio 2 wird also zur Prio 1 Regel.

Client Access Rules kennen nur zwei Aktionen: AllowAccess (Zulassen) oder DenyAccess (Verweigern). Die Aktion AllowAccess wird nicht oft zum Einsatz kommen, denn alle Aktionen die nicht per Regel verweigert werden, sind im Standard erlaubt. Da sich Regeln auch nicht auf einander aufbauen lassen (Subnetz X verweigern, aber IP auf Subnetz X erlauben), kommt AllowAccess meistens nur in der Prio 1 Regel vor (siehe Anmerkung).

Ein paar wichtige Punkte:

1. Die Exchange Management Shell nutzt RemotePowerShell für die Verbindung. Hier muss man also aufpassen, dass man sich nicht selbst aussperrt.
2. Aus Geschwindigkeitsgründen nutzen Client Access Rules einen Cache. Es kann daher bis zu 24 Stunden dauern bis die erste erstellte Regel wirkt. Änderungen an bereits bestehenden Regeln, oder das weitere hinzufügen von Regeln, können bis zu einer Stunde dauern.
3. Middle-Tier Applications wie zum Beispiel “Outlook für iOS und Android” verbinden sich nicht direkt vom Endgerät (Android Smartphone, iPhone) zum Exchange Server, sondern nutzen eine Middleware. Der Zugriff vom Client auf Exchange durchläuft also eine weitere Applikation. Dies trifft auch auf diverse Web Applikation Firewalls (WAF) zu, die im Proxy Modus arbeiten. Wenn also die IP-Adresse des Proxy/WAF/Middleware mit einer Regel blockiert wird, können ggf. viele Benutzer nicht mehr auf Exchange zugreifen. Dies gilt allerdings nicht für “Microsoft Apps” wie zum Beispiel “Outlook für iOS und Android”, hier wird zwar ebenfalls eine Middleware genutzt, diese ist aber von den Client Access Rules ausgeschlossen und können daher nicht blockiert werden (zumindest nicht mit Client Access Rules, mit Active Sync Regeln ist dieses möglich).

Beispiele für Client Access Rules

Leider gibt es an dieser Stelle nicht viele Beispiele für Client Access Rules, da es einfach derzeit nicht viele Möglichkeiten gibt. Sinnvoll sind Client Access Rules derzeit nur für das Blocken von Admin Verbindungen aus dem Internet oder anderen problematischen Netzen (ggf. Gäste WLAN oder Produktionsnetze).

Die folgende Regel blockiert die Zugriffe auf RemotePowerShell und ExchangeAdminCenter für alle Netze außer 192.168.200.0/24:

New-ClientAccessRule -Name "Block EAC and RPS" -AnyOfProtocols ExchangeAdminCenter, RemotePowerShell -Action DenyAccess -ExceptAnyOfClientIPAddressesOrRanges 192.168.200.0/24

Die folgende Regel blockiert RemotePowerShell und ExchangeAdminCenter nur für das Netz 192.168.200.0/24, lässt aber alle anderen Netze zu:

New-ClientAccessRule -Name "Block EAC and RPS" -AnyOfProtocols ExchangeAdminCenter, RemotePowerShell -Action DenyAccess -AnyOfClientIPAddressesOrRanges 192.168.200.0/24

Der folgende Befehl ändert die Netzwerke einer bestehenden Regel:

Get-ClientAccessRule "Block EAC and RPS" | Set-ClientAccessRule -AnyOfClientIPAddressesOrRanges 192.168.100.0/24, 192.168.200.0/24

Der folgende Befehl zeigt alle Regeln inkl. aller Details an:

Get-ClientAccessRule | fl *

Bestehende Regeln lassen sich mit folgendem Befehl testen, dabei wird eine Verbindung des Benutzers Administrator von der IP 192.168.100.10 zum ExchangeAdminCenter simuliert:

Test-ClientAccessRule -User administrator@frankysweblab.de -AuthenticationType Basic -RemotePort 443 -Protocol ExchangeAdminCenter -RemoteAddress 192.168.100.10

Der folgende Befehl löscht alle Regeln:

Get-ClientAccessRule | Remove-ClientAccessRule

Sobald die Client Access Regeln vollständig implementiert sind, werde ich diesen Artikel überarbeiten und weitere Beispiele einfügen.

Anmerkungen

Beim Erstellen der Regeln muss man im Hinterkopf behalten, dass immer die erste zutreffende Regel verarbeitet wird, danach aber keine weiteren Regeln angewendet werden. Hier mal ein Beispiel mit zwei Regeln, die erste verbietet den Zugriff auf EAC für das Subnetz 192.168.200.0/24, die zweite Regel erlaubt den Zugriff auf EAC von der IP 192.168.200.16:

Der Test mittel des CMDLets “Test-ClientAccessRule” liefert nun beide Regeln als Ergebnis für den Zugriff von der IP 192.168.200.16:

Hier greift aber nur die Regel mit Prio 1, auch wenn die Regel mit Prio 2 spezifischer ist:

Hier muss man also etwas aufpassen welche Regeln wie angeordnet werden, man kann sich sonst recht schnell selbst aussperren. Die Prio 1 Regel sollte daher besser nicht eine “DenyAccess” Regel sein, sondern eine “AllowAccess” Regel die den Zugriff von einem Management Netz oder Admin PC immer erlaubt.

In diesem Beispiel kann man also die Reihenfolge der Regeln verändern, damit der PC mit der IP 192.168.200.16 immer Zugriff auf EAC hat:

Viel wichtiger wäre hier natürlich der Zugriff via RemotePowerShell, da sich im Fehlerfall die Regeln nicht via EAC bearbeiten lassen, sondern nur via RemotePowerShell.

Desaster… Hilfe…!!!

Nun kann es ja doch einmal vorkommen, dass es zu einem kleinen Ausrutscher beim anlegen oder ändern von Client Access Regeln kommt. In der Exchange RTM Version lassen sich ja aktuell nur die Zugriffe auf EAC und RemotePowerShell einschränken, daher sperrt man sich als Admin also höchstens selbst aus. Benutzer sind also nicht direkt betroffen, daher erst einmal Ruhe bewahren.

Falls man sich also selbst ausgesperrt hat: Kein Problem, die Regeln werden im Active Directory gespeichert und lassen sich dort auch verändern oder löschen.

Um Regeln direkt im AD zu bearbeiteten kann der ADSI-Editor verwendet werden. Die Regeln werden in der Konfigurationspartition des AD gespeichert:

Ändert man nun die IP im Wert für “msExchTransportRuleXml” wird hier auch direkt die Regel geändert. Die Client Access Rule wird hier im XML Format gespeichert. Ich habe dazu einfach einmal die IP von 192.168.200.16 auf 192.168.200.17 geändert, dies wirkt sich auch direkt auf die Client Access Rule aus:

Falls man sich komplett verzettelt hat, lassen sich auch alle Regeln löschen, dazu können einfach die Einträge entfernt werden:

Die Exchange Shell meldet direkt das aktuelle Ergebnis, die Regeln sind gelöscht:

Hier muss dann allerdings wieder der Cache beachtet werden. Wie bereits erwähnt kann es hier bis zu einer Stunde dauern, bis der Zugriff wieder möglich ist (Alternativ Neustart der Exchange Server).

Der Beitrag Exchange 2019: Client Access Rules erschien zuerst auf Frankys Web.