Das aktuelle CU15 für Exchange Server 2019 ist, wie das CU14 auch, für Windows Server 2025 freigegeben worden. Das CU15 unterstützt das Inplace Upgrade zu Exchange Server SE RTM. Beim Inplace Upgrade wird aber nur das Upgrade der Exchange Installation unterstützt. Das Betriebssystem lässt sich nicht via Inplace Upgrade aktualisieren. Wer also ab Oktober 2025 ein Inplace Upgrade von Exchange Server 2019 CU15 zu Exchange Server SE durchführen will und auch direkt das aktuelle Windows Server Betriebssystem einsetzen möchte, kann jetzt bereits Exchange 2019 CU15 auf Windows Server 2025 installieren und eine klassische Migration durchführen. Sobald Exchange SE RTM veröffentlicht wird, muss nur noch das Inplace Upgrade durchgeführt werden.
Ich veröffentliche diesen Artikel der Vollständigkeit halber, denn die Installation ist nahezu identisch zur CU14 Installation. Dieser Artikel beschreibt die Installation von Exchange Server 2019 CU15 auf Windows Server 2025.
Windows Defender abschalten
Damit die Exchange Installation etwas schneller durchläuft, sollte während der Installation der Windows Defender abgeschaltet werden. Nach der Exchange Installation wird der Windows Defender wieder eingeschaltet. Falls ein anderer Virenscanner auf dem Server im Einsatz ist, sollte dieser ebenfalls deaktiviert werden.
Am Ende des Artikels finden sich noch die entsprechende Konfiguration mit den für Exchange erforderlichen Ausnahmen für Windows Defender.
Voraussetzungen installieren
Bevor Exchange Server installiert werden kann, müssen einige Voraussetzungen installiert werden, zunächst sind dies Windows Features, welche einfach mit der PowerShell installiert werden können:
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-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
Nachdem die Windows Features installiert wurden, müssen die erforderlichen C++ Runtimes installiert werden. Die beiden Pakete können hier runter geladen werden:
- Visual C++ Redistributable Package für Visual Studio 2012
- Visual C++ Redistributable Package für Visual Studio 2013
Zusätzlich wird das IIS URL Rewrite Modul in der 64-Bit Variante benötigt. Hier ist der entsprechende Download Link:
Aus dem Exchange ISO muss jetzt noch die UCMA 4.0 installiert werden. UCMA findet sich im ISO im Verzeichnis „UCMARedist“:
Wenn die UCMA installiert ist, sind alle Voraussetzungen installiert. Der Server sollte jetzt einmal neu gestartet werden.
Exchange 2019 CU15 Setup
Alle Voraussetzungen für Exchange sind nun installiert und es kann mit der Installation von Exchange Server begonnen werden. Dazu wird das Setup aus dem Exchange CU15 ISO gestartet:
Ich habe mal nur von den relevanten Dialogen Screenshots erstellt. Recht früh lässt sich festlegen, ob Diagnosedaten an Microsoft gesendet werden dürfen:
Die empfohlenen Einstellungen können hier abgewählt werden, so hat man mehr Kontrolle über die weiteren Einstellungen zum Setup:
Für eine Exchange 2019 Standard Installation ist nur die Mailbox Rolle erforderlich:
Im nächsten Dialog wird nach dem Installationspfad gefragt. Ich empfehle nach wie vor die Exchange Installation nicht auf C: zu installieren, sondern ein separates Laufwerk zu benutzen. In der Praxis hat sich C: für das System, D: für Exchange und weitere Volumes für die Datenbanken bewährt. Da Exchange recht viele Logs erstellt, sollte das Volume für Exchange mindestens 200 GB groß sein. Mit einem 100 GB C: Laufwerk kommt man in der Regel gut aus:
Wenn es sich um eine neue Exchange Organisation handelt, wird im nächsten Schritt nach dem Namen der Organisation gefragt. Wenn nicht wird der Readiness Check durchgeführt und Exchange kann installiert werden:
Das Setup läuft nun eine Weile:
Tipp: Stoppt euch ungefähr die Zeit, welche für die Installation benötigt wird. Jedes Exchange CU führt im Prinzip eine Neuinstallation von Exchange durch, daher kann es von Vorteil sein, wenn man die Zeit kennt, die man für die Installation von CUs einplanen muss. Mal eben in der Mittagspause könnte knapp werden.
Updates Installieren
Zum Zeitpunkt dieses Artikels gab es noch keine Sicherheitsupdates für Exchange Server 2019 CU15. Die aktuellen Sicherheitsupdates finden sich auf dieser Seite und können direkt nach der Installation des Servers installiert werden:
Windows Defender einschalten und konfigurieren
Da der Defender zu Beginn der Installation abgeschaltet wurde, ist es jetzt an der Zeit den Defender zu konfigurieren und wieder zu aktivieren.
Dazu kann das Script „Get-Exchange2019AVExclusions.ps1“ von runter geladen und auf dem Exchange Server ausgeführt werden:
Das Script erzeugt 3 Listen mit den nötigen Ausnahmen für Virenscanner. Diese Ausnahmen können auch für andere AV-Produkte verwendet werden. Das Script kann auch direkt den Windows Defender konfigurieren:
.\Get-Exchange2019AVExclusions.ps1 -ConfigureWindowsDefender
Zum Schluss nicht vergessen, dass der Windows Defender auch wieder eingeschaltet wird:
Exchange Health Checker
Die Installation ist nun bereits abgeschlossen, um zukünftige Probleme zu vermeiden, sollte der Exchange Server Health Checker ausgeführt werden. Wenn Warnungen oder Fehler auftauchen, liefert der Exchange Health Checker auch gleich einen entsprechenden Artikel zur Behebung des Problems.
Die meisten Health Checker Empfehlungen lassen sich mit einem kleinen Script umsetzen:
So sollte der Health Checker Bericht schon deutlich besser aussehen.
Was mir bei der Darstellung des Setups fehlt, ist der Aspekt des Schema-Updates. Ich gehe davon aus, dass ich das Schema-Update immer noch auf der CMD ausführen muss. In meinem Fall müsste ich nur für den Punkt einen Kollegen mit höheren Rechten dazuholen.
Was mir bei Frankys Test-Umgebung fehlt, ist ein Loadbalancer bzw. die Frage, ob und wann ich den neuen Produktiv-Ex2019-Server am Loadbalancer einhängen kann. Aber vllt. wird das noch erwähnt.
Als quick and dirty Variante, wenn man sich den leidigen (weil über MAPI) Umzug der ganzen Postfächer sparen will, kann man auch die Datenbank dismounten, auf den neuen Server kopieren und hier wieder einhängen mit dem Parameter -AllowFileRestore $true. Anschließend Get-Mailbox -Database „NeuerName“ | Set-Mailbox -Database „AlterName“ um die Mailboxen wieder mit der neuen Datenbank zu verknüpfen.
Ist aber mit einer Donwtime verbunden und eher für DisasterRecovery gedacht.
Richtig, aber mach das mal, wenn deine DB 800GB und größer ist und du davon nicht nur eine sondern 17 hast. ;) Viel Spaß beim Kopieren.
Wenn man mit VMs arbeitet, die Exchange Version auf beiden Servern identisch ist und die DBs auf einer separaten Platte hat, würde es eigentlich funktionieren die Datenbanken auf dem alten Server zu dismounten, die Platte auf der alten VM auszuhängen, an den neuen Server anzuhängen und dann die DBs dort hinzuzufügen/ zu mounten? Das würde einem das kopieren ersparen, wenn man nicht alle Postfächer verschieben möchte. Oder wäre das auch eher in die Kategorie „Gebastel“ zu stecken?
Grundsätzlich kann man das machen. Hat halt in jedem Fall eine wie auch immer geartete Downtime zur Folge und man hantiert zwangsweise immer mit den Originaldaten. Wenn also was schief geht, hat man hoffentlich ein aktuelles Backup zur Hand. :)
Ist hier bei MS dokumentiert:
https://learn.microsoft.com/de-de/exchange/high-availability/disaster-recovery/database-portability?view=exchserver-2019
Wenn Datenbankportabilität zur Wiederherstellung einer Postfachdatenbank verwendet wird, müssen die Version des Betriebssystems und die Exchange Server-Version auf den Quell- und Ziel-Exchange-Servern übereinstimmen. Beispiel: Wenn eine Exchange 2016-Postfachdatenbank auf einem Server unter Windows Server 2016 bereitgestellt wurde, funktioniert Datenbankportabilität nur, wenn die Datenbank auch zu einem Server unter Windows Server 2016 und Exchange 2016 migriert wird.
Somit also ggf. auch unsupported. Womit wir wieder bei „kann gehen“ landen. Ich verstehe nicht, warum sich soviele gegen eine einfache Migration sträuben. Dauert am Ende auch nicht viel länger.
Ich sträube mich nicht vor der normalen Migration, das war von mir nur ein Gedankenspiel, um ggfls. die Migrationszeit der Postfächer zu verkürzen, die sind bei uns teilweise recht groß.
Wenn wir später vom Server 2019 auf was neueres migrieren mache ich das dann halt klassisch, ich möchte auf keinen Fall eine unsupportete Umgebung haben. SE läuft ja auch erst mal auf Server 2019.
Während der Mailbox Verschiebung merkt doch kein User was davon und ob das nu 1h oder 2 Wochen dauert ist doch total egal.
Warum eigentlich (wieder) eine Anleitung für die Installation auf einem Server mit GUI?
Die GUI braucht man ja höchstens noch für die Toolbox (Warteschlangen-Viewer), aber den kann man sich ja auf jeden x-belibigen anderen Server installieren.
Ich lese die Kommentare von Norbert und dartzen sehr oft und denke mir oft, ja okay, support hin oder her, aber versucht es doch einfach mal. Ich habe bei Exchange Server schon seit Server 2019 mindestens 8x das Inplace Upgrade auf Server 2022 und auch jetzt schon 2x das Inplace Upgrade auf Server 2025 in produktiven Exchange Umgebungen genutzt. Ich habe es mir allerdings immer so gelegt, dass ich nach dem OS Inplace Upgrade noch ein CU zu installieren habe, das fühlte sich für mich immer besser an. Aber erst diesen Monat zuletzt lief der Exchange 2019 auch ohne CU15 Update ganz normal auf dem CU14 weiter, nachdem ich das Inplace gemacht hatte. Aber dann über den „neuen“ Server ein CU Update, was ja eine volle Installation ist, laufen zu lassen, fühlt sich für mich einfach besser an.
Es geht nicht darum ob es geht, sondern darum was vom Hersteller vorgegeben wird. MS schreibt es explizit, dass es nicht supported ist. Ist schön für dich wenn du es probieren willst, aber empfehlen werde ich das niemandem. Zum einen hat es in der Vergangenheit schon Exchange Server dabei zerschossen. Und zum anderen, was machst du wenn es zwar erst mal läuft, es aber dann irgendwann zu Problemen im Betrieb kommt? Der MS Support wird mit ziemlicher Sicherheit feststellen, dass hier ein In-Place Upgrade durchgeführt wurde und dann den Support verweigern. Und dann hast du den Salat.
Was man privat macht ist einem selbst überlassen, aber im geschäftlichen Umfeld sollte man sich nie außerhalb der vorgegebenen Bedingungen des Herstellers begeben.
Sollten diese Exchange Server irgendwann mal Probleme machen, dann kann man immer noch die Mailboxen auf einen frisch installierten Server umziehen, bis dahin spare ich mir aber gerne die Zeit ;-) Und wer weiß, vielleicht wird es ja irgendwann mal supported, so wie CU14 dann doch noch nachträglich für Server 2025 den Support bekommen hat. Und ich hatte auch schon den Fall, dass ein Exchange Probleme hatte (hatte nichts mit dem Inplace zu tun) und MS dann trotzdem geholfen hat – sie haben gar nicht geprüft ob es mal ein OS-Inplace gab.
Aber klar EMPFEHLEN würde ich es auch niemandem, da es nicht supported ist. Aber es funktioniert seit Jahren ohne Probleme.
Ich habs bei Kunden gesehen, was hinterher nicht ging (gabs auch Kandidaten hier im Forum). Ja kann man alles irgendwie fixen wenn man es unbedingt so haben will. Aber da ich Dienstleister bin, halte ich mich in dem Fall an die Supportzusagen des Herstellers und fange nicht an irgendwas zu basteln. Wer das mag kann es ja gern tun und sich freuen wenn alles läuft. Der Zeitaufwand ist mit ca. 2h wenn alles gut geht vermutlich überschaubar. Dafür haste aber auch 2h Downtime deines Exchangeservers.
Ich bin auch Dienstleister und habe über diesen Weg noch nie etwas zu fixen gehabt, läuft wunderbar ;-) aber grundsätzlich bin ich schon bei dir, dass es besser ist sich an den supporteten Weg zu halten.
Wir haben noch viele Installationen EX2019 CU14 und Win Server 2019
hat schon jemand inplace upgrades versucht, also
EX2019 CU 14 -> CU 15 (klappt ja problemlos)
und danach Win Server 2019 -> 2025
Wie oft denn nun noch. Steht sicher in den ganzen anderen Kommentaren ebenfalls. Ein inplace Upgrade des os mit installierten Exchange ist derzeit und für die nächste Zukunft nicht supported. Wer also von Windows 2019 zu 2025 will, muss klassisch einen zweiten Exchange installieren und die Funktionen und Mailboxen dahin umziehen.
https://techcommunity.microsoft.com/blog/exchange/upgrading-your-organization-from-current-versions-to-exchange-server-se/4241305
“Will Exchange Server SE allow in-place upgrade of Windows Server operating system while Exchange is already installed?
No. Upgrades of the underlying Windows OS on an Exchange Server are not supported and will remain unsupported. We have heard this request and are evaluating it (but have nothing to announce currently). For customers building new servers, we encourage you to install the newest Windows OS before installing Exchange Server on it (including Windows Server 2025 once Exchange 2019 CU15 is released).”
Du kannst das OS mit installiertem Exchange nicht In-Place upgraden, das ist nicht supported und war es auch nie, daher macht diese Abfolge keinen Sinn. Wenn du auf Server 2025 gehen willst ist das richtige Szenario einfach einen neuen Server 2025 aufsetzen, dort Exchange 2019 CU15 installieren und dann eine Migration der Daten vom „alten“ Exchange auf die neue Maschine machen. Anschließend den alten Exchange deinstallieren. Die CU15 Installation auf dem alten Exchange kannst du dir sparen.