Eine Frage an die Community:
Da demnächst ein Upgrade unseres Mailservers mit Windows Server 2012R2 und Exchange 2016 CU23 auf Windows Server 2019(I know, nicht offiziell supported) ansteht und wir neben der Neuinstallation auch ein Inplace-Upgrade in Erwägung gezogen haben, haben wir das natürlich auch intern im Surebackup getestet:
Ergebnis: unter 2012R2 funktioniert der (interne) Mailversand tadellos, wie auf der Maschine im produktiven Betrieb auch.
Nach einem optisch(!) problemlosen Upgrade auf Server 2016 oder Server 2019 Standard werden alle Dienste hochgezogen, man kann sich auch ins OWA verbinden. Nachdem aber eine Testmail versandt wurde, offenbart sich im Eventviewer folgende Meldung:
Ereignis 7031:
Der Dienst "Microsoft Exchange-Postfachtransportzustellung" wurde unerwartet beendet. Dies ist bereits 1 Mal vorgekommen. Folgende Korrekturmaßnahmen werden in 5000 Millisekunden durchgeführt: Neustart des Diensts.
Detailansicht:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" />
<EventID Qualifiers="49152">7031</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2023-03-08T15:47:17.857742100Z" />
<EventRecordID>1788</EventRecordID>
<Correlation />
<Execution ProcessID="620" ThreadID="4340" />
<Channel>System</Channel>
<Computer>E**************.***</Computer>
<Security />
</System>
- <EventData>
<Data Name="param1">Microsoft Exchange-Postfachtransportzustellung</Data>
<Data Name="param2">1</Data>
<Data Name="param3">5000</Data>
<Data Name="param4">1</Data>
<Data Name="param5">Neustart des Diensts</Data>
<Binary>4D005300450078006300680061006E0067006500440065006C00690076006500720079000000</Binary>
</EventData>
</Event>
Der betroffene Dienst wird danach automatisch wieder gestartet, die versandte Mail aber nicht zugestellt.
Das Problem ist reproduzierbar.
Die Bindings scheinen in Ordnung, ebenso die Zertifikate. Der Virenscanner wurde zu Testzwecken deaktiviert.
Eventuell hat von euch jemand eine Ahnung, woran das liegen könnte.
Als letzte Option bleibt ohnehin nur eine komplette Neuinstallation des Servers.
Ich bin für jeden Tipp dankbar, lg
I know, nicht offiziell supported) ansteht und wir neben der Neuinstallation auch inplace
Eigentlich reicht das aus. Es wird niemand sagen können oder wollen ob und wie es geht und du willst nicht später bei jedem Problem fragen ob das nachwehen dieser Aktion wären.
was spricht denn gegen den offiziellen und funktionierenden weg?
Es bleibt zu sagen, dass unter Windows Server 2016 1:1 dasselbe Problem auftritt - und das ist supported.
Warum die Möglichkeit des Inplace-Upgrades in Erwägung gezogen wurde? Weil es möglicherweise, sofern nix anderes auftaucht, wesentlich weniger Aufwand bedeuten würde.
@mcrob83 es bleibt auch zu sagen, dass OS Inplace Upgrades mit installiertem Exchange noch nie supported waren. Das ist für Exchange 2019 irgendwann mal geplant, aber derzeit gibts keine Exchange Version die das "überlebt" und hinterher supported wäre.
wesentlich weniger Aufwand bedeuten würde.
Sieht man ja grad. ;)
@mcrob83 es bleibt auch zu sagen, dass OS Inplace Upgrades mit installiertem Exchange noch nie supported waren. Das ist für Exchange 2019 irgendwann mal geplant, aber derzeit gibts keine Exchange Version die das "überlebt" und hinterher supported wäre.
wesentlich weniger Aufwand bedeuten würde.
Sieht man ja grad. ;)
Danke, da hier nichts konstruktives mehr kommt, Thema erledigt.
Es ist nun mal unsupported und macht nachweislich Probleme. Machs richtig, dann gibts weniger/keine Probleme und du hast die Möglichkeit die Fehler sinnvoll zu lösen.
Wenn dir das unkonstruktiv erscheint, kann ich dir leider nicht helfen.
Schönen Tag noch
Norbert
Bitte komplett lesen - respektive mindestens über den ersten Satz...
Inplace funktioniert meist problemlos bei Windows Server mit diversen Diensten.
Aber gerade bei Exchange und WSUS, also die Dienste die wahrscheinlich fast alle haben, weiss man von diversen Problemen.
Exchange soll seit jeher kein Windows Inplace Update vertragen. Und wirds wohl auch nur bedingt in Zukunft. Ich glaube der einzige Weg der Momentan geplant ist, ist ein Inplace von Exchange 2019 auf Exchange "Zukunft", aber auch da hat niemand von einem Windows Inplace gesprochen, wenn ich mich korrekt erinnere.
Bis jetzt haben die Migrationen mit einem zweiten Exchange installieren und migrieren von Postfächern immer sehr gut funktioniert. Und da hast du auch bessere "Zurück" Möglichkeiten.
Wenn du via Inplace migrierst, darfst du eigentlich nicht mehr zurück, du hast dann in der Domäne auch schon Änderungen.
Du kannst dir hier wirklich fast nur Probleme einhandeln. Die du schlimmstenfalls Monate, Jahre danach findest.
Exchange soll seit jeher kein Windows Inplace Update vertragen.
Das "soll" kannst du streichen. Exchange verträgt kein Inplace Upgrade und selbst wenn es "funktionieren" sollte, wird man damit nicht glücklich.
Die erwähnte Migration ist die derzeit einzige Methode um OS und/oder Exchange auf eine neue/andere Version zu bringen. Immer auch unter Berücksichtigung der Kompatibilitätsmatrix.
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix
Da stehts für 2019 sogar drin (ähnliche Situation wie für 2016 2012R2 auf 2016):
In-place upgrades from Windows Server 2019 with Exchange 2019 installed to Windows Server 2022 are not supported.