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:
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.
Hallo werte Leidensgenossen,
eine kurze Frage:
nach der erfolgreichen Migration auf Exchange 2019 werden unsere OWA Verzeichnisse immer noch als „OwaVersion“ Exchange2013 angezeigt.
Ist dies so korrekt?
Wenn ich mich per OWA anmelde wird die Seite auch schon im neuen Style angezeigt, sollte also meiner Meinung nach passen.
Vielen Dank für eure Auskunft im Voraus.
MfG Gabriel
Guten Morgen,
kann es sein, dass bei der Coexistenz von Exchange 2016 und 2019 die Client Access Rules auf den 2019 Servern nicht funktionieren? Nach der Einrichtung der Regeln ist der Zugriff auf das ECP & RPS weiterhin möglich. Bis jetzt hat die Einrichtung der Regeln in Umgebungen mit ausschließlich 2019er Servern immer problemlos funktioniert.
Hallo Patrick
Das sollte nur dann passieren, wenn Du auf das ECP des 2016er Exchange zugreifst, da diese die Client Access Rules nicht unterstützt.
Wenn Du das ECP des 2019er mit der Erweiterung der Version in der URL explizit aufrufst, sollte es hingegen funktionieren:
https://server.domain.tld/ecp/?ExchClientVer=15.2
Ob und wie man den ECP-Zugriff auf den 2016er komplett unterbinden kann, dazu habe ich bisher aber auch noch keine brauchbare Lösung, ausser den 2016er zu deinstallieren.
Hallo,
nach der Migration können sich die Benutzer nicht mehr anmelden, weder in OWA noch Outlook. Wird immer mit falscher Benutzername oder Passwort abgelehnt.
ich bräuchte dringend Hilfe
Hallo Zusammen,
ich habe ein Problem bei der Deinstallation des Exchange 2016. Folgende Fehlermeldung:
Beim Zugriff auf die Registrierung auf diesem Computer ist ein Problem aufgetreten. Dies kann passieren, wenn der Remoteregistrierungsdienst nicht ausgeführt wird. Es kann auch ein Hinweis auf ein Netzwerkproblem oder darauf sein, dass der TCP/IP-NetBIOS-Hilfsdienst nicht ausgeführt wird.
Namensauflösung funktioniert, Netzwerk habe ich keine Probleme, die in der Fehlermeldung erwänten Dienste laufen alle, auch ein Neustart hat nichts gebracht.
hat jemand eine Idee?
Das ist zwar schon etwas länger her, aber eine Option wäre es, dass man in den OWA Einstellungen überprüfen muss, ob eine Domäne automatisch verwendet wird und somit nur der Benutzername ohne „Domäne\“ eingegeben werden muss.
Vielleicht hat dies jemand auch vergessen
Guten Tag,
ich habe die Migration nach Anleitung durchgeführt und alles scheint funktioniert zu haben. Wenn ich allerdings den DNS auf den neuen Server 2019 setze, kann Outlook sich nicht mehr anmelden. Es wird nach dem Passwort gefragt und trotz Eingabe des richtigen Passworts verbindet Outlook sich nicht. OWA und Outlook Anywhere funktionieren.
Hat jemand eine Idee?
Hi,
vielen Dank für diese geniale Anleitung. Damit klappte der Umstieg von 2016 auf 2019 vollkommen schmerzfrei!!
Ich ziehe gerade eine Menge Exchangeserver um… Sicherheitslücke lässt grüßen.
Und ich bin überaus dankbar für diese grandiose Anleitung!!
Ein Hinweis: Ich fange immer mit den Migration-Tasks an, da kann man auch die Systempostfächer mit umziehen.
Möglicherweise nicht der korrekte Weg, aber es funktioniert.
Danke nochmals
Hat bei mir auch in egal welcher Reihenfolge ohne Probleme geklappt.
Für Server mit mehreren Datenbanken hier noch der generelle Befehl:
Ersetze Servername mit dem Namen deines Server.
get-mailbox -server SERVERNAME -Arbitration
get-mailbox -server SERVERNAME -Archive
get-mailbox -server SERVERNAME -PublicFolder
get-mailbox -server SERVERNAME -AuditLog
ALLE müssen nach dem Umzug nichts mehr zurückmelden!
Hallo.
Da ich per Goolge nichts darüber finde (bzw. nur in Verbindung mit DAG, was ich nicht habe) versuche ich es Mal hier, auch wenn dies evtl. nicht die passende Rubrik/Anlaufstelle ist:
Ich möchte bei einem Exchange 2016 das Subnet ändern (254 zu 252). Das geht auch ohne Schwierigkeiten, jedoch lässt sich nach dem Neustart der Transport Service nicht mehr starten. Ist ein Single Exchange, Standard-Installation ohne DAG etc.
Hab schon 3 Mal alle Einstellungen durch, finde aber nichts bezüglich der Subnetmask.
Da muss doch bestimmt im „Inneren“ irgendwo noch die Subnetmask geändert werden!?
Hat jemand ’nen Tip für mich?
Hi,
mir ist eine Kleinigkeit aufgefallen, mit der man sich etwas komplexe Tipparbeit sparen kann. Get-MoveRequest unterstützt den Parameter -MoveStatus mit der Parametern Completed, InProgress usw. das ist schneller zu tippen statt des where { $_… Konstrukts.
Viele Grüße.
Hallo Frank!
Vielen Dank für die ausführliche Anleitung!
Ich habe inzwischen mehrere Migrationen von 2010 nach 2019 über den Zwischenschritt 2016 hinter mir. Jedesmal ist mir beim Entfernen des Ex2016 folgendes passiert:
Ich wollte zuerst die EX2016 Datenbank löschen und bekam immer eine Fehlermeldung, dass noch ein PublicFolderMoveRequest aktiv sei und die Datenbank sich deswegen nicht löschen läßt. Natürlich bekam ich mit Get-publicFolderMoveRequest nichts angezeigt, was ich hätte mit Remove-PublicfolderMoveRequest hätte löschen können, so wie mir die Fehlermeldung es weiss machen wollte. Inzwischen kenne ich natürlich einen Workarround:
Auf einem DC ADSI-Edit starten, dort Unter Konfiguration/Services/Microsoft Exchange/“Org-Name“/Mailbox Replication/PublicFolderMailboxMigrationRequest rechts den kryptischen Eintrag mit der GUID entfernen. Danach lässt sich die Datenbank löschen und auch Exchange deinstallieren. Natürlich kann man alternativ direkt die Datenbank im AD mittels ADSI-Edit löschen, so finde ich es aber sauberer.
Dies für alle, die in den gleichen Fehler laufen
Moin, wollte einfach nur mal Danke sagen! Deine Anleitung sind einfach super! Also Vielen Dank!
Hallo Franky,
erstmal vielen Dank für die Super Anleitung.
Hat weitestgehend alles ohne Probleme funktioniert und das obwohl das testsystem das ich hier hatte zimelich verrichtet ist. habe das ganze sogar von einem alten SBS umgezogen, mit deiner Anleitung.
So nun kurz vor dem Ziel, habe ich aber ein Problem, das sich nicht lösen lässt.
Die Deinstallation des temporären Exchange 2016 Servers.
JHatte den Server jetzt 2 Wochen aus und alles lief ohne Probleme. Wollte ihn nun am Wochenende endlich entfernen, und dann das:
Fehler: Der folgende Fehler wurde generiert, als „$error.Clear(); $dllFile = join-path $RoleInstallPath „bin\ExSMIME.dll“; $regsvr = join-path (join-path $env:SystemRoot system32) regsvr32.exe; start-SetupProcess -Name:“$regsvr“ -Args:“/s /u `“$dllFile`““ -Timeout:120000; “ ausgeführt wurde: „Microsoft.Exchange.Configuration.Tasks.TaskException: Fehler bei der Prozessausführung mit Beendigungscode 5. bei Microsoft.Exchange.Management.Tasks.RunProcessBase.InternalProcessRecord() bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1() bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.
Mal schnell gegoogelt und folgende „Lösung“ gefunden:
Go to folder C:\Program Files\Microsoft\Exchange Server\V15\bin- This should have Exmime.dll file. This file works with regsvr32.exe /u without any error. To fix the error above : move original ExSMIME.dll in different location and rename & copy exmime.dll as ExSMIME.dll. Then run the uninstall again- Setup.exe /mode:Uninstall /IAcceptExchangeServerLicense to finish uninstall Exchange
Beendet die Deinstallation leider mit dem Fehler:
Exception : Microsoft.Exchange.Management.Deployment.ScriptExecutionException: Der folgende Fehler wurde generiert, als „$error.Clear(); $RoleBinPath = ‚C:\Program Files\Microsoft\Exchange Server\V15\Bin'“ ausgeführt wurde: „System.Management.Automation.RuntimeException: Fehler beim Erstellen der Pipeline —> System.IO.FileNotFoundException: C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
bei System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
bei System.Diagnostics.ProcessModule.get_FileVersionInfo()
bei System.Management.Automation.AmsiUtils.Init()
bei System.Management.Automation.AmsiUtils.ScanContent(String content, String sourceMetadata)
bei System.Management.Automation.CompiledScriptBlockData.PerformSecurityChecks()
bei System.Management.Automation.CompiledScriptBlockData.ReallyCompile(Boolean optimize)
bei System.Management.Automation.CompiledScriptBlockData.CompileUnoptimized()
bei System.Management.Automation.CompiledScriptBlockData.Compile(Boolean optimized)
bei System.Management.Automation.DlrScriptCommandProcessor.Init()
bei System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory, CommandOrigin origin)
bei System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
— Ende der internen Ausnahmestapelüberwachung —
bei System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
bei System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
bei Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)“. —> System.Management.Automation.RuntimeException: Fehler beim Erstellen der Pipeline —> System.IO.FileNotFoundException: C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
bei System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
bei System.Diagnostics.ProcessModule.get_FileVersionInfo()
bei System.Management.Automation.AmsiUtils.Init()
bei System.Management.Automation.AmsiUtils.ScanContent(String content, String sourceMetadata)
bei System.Management.Automation.CompiledScriptBlockData.PerformSecurityChecks()
bei System.Management.Automation.CompiledScriptBlockData.ReallyCompile(Boolean optimize)
bei System.Management.Automation.CompiledScriptBlockData.CompileUnoptimized()
bei System.Management.Automation.CompiledScriptBlockData.Compile(Boolean optimized)
bei System.Management.Automation.DlrScriptCommandProcessor.Init()
bei System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory, CommandOrigin origin)
bei System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
— Ende der internen Ausnahmestapelüberwachung —
bei System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
bei System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
bei Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)
— Ende der internen Ausnahmestapelüberwachung —
bei Microsoft.Exchange.Management.Deployment.ComponentInfoBasedTask.InternalExecuteScript(String script, Boolean handleError, Int32 subSteps, LocalizedString statusDescription)
bei Microsoft.Exchange.Management.Deployment.ComponentInfoBasedTask.ExecuteScript(String script, Boolean handleError, Int32 subSteps, LocalizedString statusDescription)
bei Microsoft.Exchange.Management.Deployment.ComponentInfoBasedTask.GenerateAndExecuteTaskScript(InstallationCircumstances installationCircumstance)
[04.17.2020 18:48:32.0322] [1] [ERROR] The following error was generated when „$error.Clear(); $RoleBinPath = ‚C:\Program Files\Microsoft\Exchange Server\V15\Bin'“ was run: „System.Management.Automation.RuntimeException: Fehler beim Erstellen der Pipeline —> System.IO.FileNotFoundException: C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
bei System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
bei System.Diagnostics.ProcessModule.get_FileVersionInfo()
bei System.Management.Automation.AmsiUtils.Init()
bei System.Management.Automation.AmsiUtils.ScanContent(String content, String sourceMetadata)
bei System.Management.Automation.CompiledScriptBlockData.PerformSecurityChecks()
bei System.Management.Automation.CompiledScriptBlockData.ReallyCompile(Boolean optimize)
bei System.Management.Automation.CompiledScriptBlockData.CompileUnoptimized()
bei System.Management.Automation.CompiledScriptBlockData.Compile(Boolean optimized)
bei System.Management.Automation.DlrScriptCommandProcessor.Init()
bei System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory, CommandOrigin origin)
bei System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
— Ende der internen Ausnahmestapelüberwachung —
bei System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
bei System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
bei Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)“.
[04.17.2020 18:48:32.0322] [1] [ERROR] Fehler beim Erstellen der Pipeline
[04.17.2020 18:48:32.0322] [1] [ERROR] C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
[04.17.2020 18:48:32.0322] [1] [WARNING] An unexpected error has occurred and a Watson dump is being generated: Der folgende Fehler wurde generiert, als „$error.Clear(); $RoleBinPath = ‚C:\Program Files\Microsoft\Exchange Server\V15\Bin'“ ausgeführt wurde: „System.Management.Automation.RuntimeException: Fehler beim Erstellen der Pipeline —> System.IO.FileNotFoundException: C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
bei System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
bei System.Diagnostics.ProcessModule.get_FileVersionInfo()
bei System.Management.Automation.AmsiUtils.Init()
bei System.Management.Automation.AmsiUtils.ScanContent(String content, String sourceMetadata)
bei System.Management.Automation.CompiledScriptBlockData.PerformSecurityChecks()
bei System.Management.Automation.CompiledScriptBlockData.ReallyCompile(Boolean optimize)
bei System.Management.Automation.CompiledScriptBlockData.CompileUnoptimized()
bei System.Management.Automation.CompiledScriptBlockData.Compile(Boolean optimized)
bei System.Management.Automation.DlrScriptCommandProcessor.Init()
bei System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory, CommandOrigin origin)
bei System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
— Ende der internen Ausnahmestapelüberwachung —
bei System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
bei System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
bei Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)“.
[04.17.2020 18:48:32.0490] [1] [ERROR] Der folgende Fehler wurde generiert, als „$error.Clear(); $RoleBinPath = ‚C:\Program Files\Microsoft\Exchange Server\V15\Bin'“ ausgeführt wurde: „System.Management.Automation.RuntimeException: Fehler beim Erstellen der Pipeline —> System.IO.FileNotFoundException: C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
bei System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
bei System.Diagnostics.ProcessModule.get_FileVersionInfo()
bei System.Management.Automation.AmsiUtils.Init()
bei System.Management.Automation.AmsiUtils.ScanContent(String content, String sourceMetadata)
bei System.Management.Automation.CompiledScriptBlockData.PerformSecurityChecks()
bei System.Management.Automation.CompiledScriptBlockData.ReallyCompile(Boolean optimize)
bei System.Management.Automation.CompiledScriptBlockData.CompileUnoptimized()
bei System.Management.Automation.CompiledScriptBlockData.Compile(Boolean optimized)
bei System.Management.Automation.DlrScriptCommandProcessor.Init()
bei System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory, CommandOrigin origin)
bei System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
— Ende der internen Ausnahmestapelüberwachung —
bei System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
bei System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
bei Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)“.
[04.17.2020 18:48:32.0490] [1] [ERROR] The following error was generated when „$error.Clear(); $RoleBinPath = ‚C:\Program Files\Microsoft\Exchange Server\V15\Bin'“ was run: „System.Management.Automation.RuntimeException: Fehler beim Erstellen der Pipeline —> System.IO.FileNotFoundException: C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
bei System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
bei System.Diagnostics.ProcessModule.get_FileVersionInfo()
bei System.Management.Automation.AmsiUtils.Init()
bei System.Management.Automation.AmsiUtils.ScanContent(String content, String sourceMetadata)
bei System.Management.Automation.CompiledScriptBlockData.PerformSecurityChecks()
bei System.Management.Automation.CompiledScriptBlockData.ReallyCompile(Boolean optimize)
bei System.Management.Automation.CompiledScriptBlockData.CompileUnoptimized()
bei System.Management.Automation.CompiledScriptBlockData.Compile(Boolean optimized)
bei System.Management.Automation.DlrScriptCommandProcessor.Init()
bei System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory, CommandOrigin origin)
bei System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
— Ende der internen Ausnahmestapelüberwachung —
bei System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
bei System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
bei Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)“.
[04.17.2020 18:48:32.0490] [1] [ERROR] Fehler beim Erstellen der Pipeline
[04.17.2020 18:48:32.0490] [1] [ERROR] C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
[04.17.2020 18:48:32.0499] [0] [ERROR] Ein Aufrufziel hat einen Ausnahmefehler verursacht.
[04.17.2020 18:48:32.0500] [0] [ERROR] Der folgende Fehler wurde generiert, als „$error.Clear(); $RoleBinPath = ‚C:\Program Files\Microsoft\Exchange Server\V15\Bin'“ ausgeführt wurde: „System.Management.Automation.RuntimeException: Fehler beim Erstellen der Pipeline —> System.IO.FileNotFoundException: C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
bei System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
bei System.Diagnostics.ProcessModule.get_FileVersionInfo()
bei System.Management.Automation.AmsiUtils.Init()
bei System.Management.Automation.AmsiUtils.ScanContent(String content, String sourceMetadata)
bei System.Management.Automation.CompiledScriptBlockData.PerformSecurityChecks()
bei System.Management.Automation.CompiledScriptBlockData.ReallyCompile(Boolean optimize)
bei System.Management.Automation.CompiledScriptBlockData.CompileUnoptimized()
bei System.Management.Automation.CompiledScriptBlockData.Compile(Boolean optimized)
bei System.Management.Automation.DlrScriptCommandProcessor.Init()
bei System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory, CommandOrigin origin)
bei System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
— Ende der internen Ausnahmestapelüberwachung —
bei System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
bei System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
bei Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)“.
[04.17.2020 18:48:32.0500] [0] [ERROR] The following error was generated when „$error.Clear(); $RoleBinPath = ‚C:\Program Files\Microsoft\Exchange Server\V15\Bin'“ was run: „System.Management.Automation.RuntimeException: Fehler beim Erstellen der Pipeline —> System.IO.FileNotFoundException: C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
bei System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
bei System.Diagnostics.ProcessModule.get_FileVersionInfo()
bei System.Management.Automation.AmsiUtils.Init()
bei System.Management.Automation.AmsiUtils.ScanContent(String content, String sourceMetadata)
bei System.Management.Automation.CompiledScriptBlockData.PerformSecurityChecks()
bei System.Management.Automation.CompiledScriptBlockData.ReallyCompile(Boolean optimize)
bei System.Management.Automation.CompiledScriptBlockData.CompileUnoptimized()
bei System.Management.Automation.CompiledScriptBlockData.Compile(Boolean optimized)
bei System.Management.Automation.DlrScriptCommandProcessor.Init()
bei System.Management.Automation.Runspaces.Command.CreateCommandProcessor(ExecutionContext executionContext, CommandFactory commandFactory, Boolean addToHistory, CommandOrigin origin)
bei System.Management.Automation.Runspaces.LocalPipeline.CreatePipelineProcessor()
— Ende der internen Ausnahmestapelüberwachung —
bei System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
bei System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
bei Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)“.
[04.17.2020 18:48:32.0500] [0] [ERROR] Fehler beim Erstellen der Pipeline
[04.20.2020 18:48:32.0500] [0] [ERROR] C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
[04.17.2020 18:48:32.0500] [0] CurrentResult SetupLauncherHelper.loadassembly:444: 1
[04.17.2020 18:48:32.0500] [0] Setup von Exchange Server wurde nicht abgeschlossen. Weitere Details finden Sie im Protokoll ‚ExchangeSetup.log‘ im Ordner ‚:\ExchangeSetupLogs‘.
[04.17.2020 18:48:32.0500] [0] CurrentResult main.run:235: 1
[04.17.2020 18:48:32.0500] [0] Der Registrierungsschlüssel „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\V15\Setup“ wurde nicht gefunden.
[04.17.2020 18:48:32.0500] [0] CurrentResult setupbase.maincore:396: 1
[04.17.2020 18:48:32.0501] [0] End of Setup
[04.17.2020 18:48:32.0501] [0] **********************************************
Habe nun also eine funktionierende Ex2019 Installation und eine kaputte Ex2016.
Bekomm ich das irgendwie sauber gelöst oder bleibt mir nichts anderes übrig, als Ex 2016 manuell zu entfernen überall?
Vielleicht hast ja eine Idee für mich.
Ich wusste nicht genau,wohin mit meiner Frage, deswegen hier:
Exchange 2019 – kleine private Umgebung
mit der Abfrage: Get-TransportConfig | fl InternalSMTPServers bekomme ich 2 IPs angezeigt: 192.168.0.2 und 0.36
die IP des Servers hat sich aber inzwischen geändert (er hat im Moment zwei (virtuelle) Netzwerkkarten (läuft auf Hyper-V) und die Adressen: 192.168.0.35, sowie 192.168.178.13). Wie bekomme ich die IP´s umgestellt, bzw. diese beiden SMTP-Server weg und nen neuen rein?
Beste Grüße
Jörg
Hallo Frank,
also erstmal muss ich ein riesen Lob an dich senden. Durch deine Anleitungen habe ich es geschafft einen SBS2011 mit Exchange 2010 anzulösen. Erstmal die Migration auf 2016 und nun die 2016 auf 2019. Dabei hatte ich viele Stolperfallen. Die erste 2019er Installation ging völlig in die Hose. Selbst deine Anleitung zum manuellen Entfernen eines Exchange hat super geklappt. Mir war zwar ganz übel beim löschen, andererseits gab es keine andere Möglichkeit.
Nun habe ich aber folgendes Szenario:
Migration 2016 zu 2019 komplett nach deiner Anleitung. Mailboxen, Systempostfächer, ÖO sind alle umgezogen. Ich wollte den Exchange 2016 noch nicht deinstallieren bevor ich alles austeste also habe ich die VM erstmal runtergefahren. Am Montag bekam ich dann aus der Firma einen Anruf das wohl garnix mehr geht… Also VM wieder hochgefahren und alles läuft… (Paralelbetrieb 2016+2019). Wird sich das ändern wenn ich 2016 deinstalliere? Werden bei der Deinstallation irgendwelche schritte abgearbeitet die dazu führen dass 2019 problemlos läuft oder ist das eher unwahrscheinlich?
Ausserdem empfangen die Handys keine Mails mehr, wenn sie am internen WLAN hängen. Von aussen läuft alles prima.
Wäre dir super dankbar für eine Antwort. Deine Anleitungen sind echt der HIT! Einfach spitze. Mach weiter so!
DAAANNNKKKEEE
Hallo nochmals,
ich beantworte die Frage selbst:
Da waren wohl noch einige DNS-Einträge auf die IP des 2016er Servers gelinkt. Nachdem ich diese geändert hatte, lief auch alles wieder.
Kann man auch mehrere Addressbereiche aus der Clientaccessrule ausschließen? Ich würde gerne das interne und das VPN Netzwerk ausschließen.
Ein Komma hinter dem ersten Bereich und dann der nächste Adressbereich aufgeführt sollte das tun. (Sagt zumindest https://docs.microsoft.com/en-us/powershell/module/exchange/set-clientaccessrule?view=exchange-ps).
Leider sehe ich hier gerade, dass mein Remotesystem im zweiten erlaubten Netz ebenfalls gesperrt wird und bin mir nicht sicher, wieso. Können da zusätzliche Netzwerkadapter (von Hyper-V erzeugt) im zugreifenden System eine Rolle spielen?
Hallo Frank,
die ClientAccessRule scheint bei einem Reverse-Proxy durch die UTM nicht zu greifen.
Ich habe auf der Firewall in den Exceptions sowohl das /ecp/* als auch das /ecp/* entfernt, komme aber immer noch auf den Admin Center über Externen Aufruf mit /ecp.
Hallo Eric,
die Client Access Rule welche den Zugriff auf EAC einschränkt muss die IP des Reverse Proxys enthalten, dies wäre also die Interface IP der UTM welche im Subnetz des Exchange Servers hängt.
Gruß,
Frank
Wir haben bei uns eine ähnliche Struktur wie Du.
2x Exch2016 in einer DAG, Sophos UTM 9.6, Kemp Loadbalancer.
Wir haben nun einen ersten Exch2019 dazugefügt.
Zuerst sah auch alles gut aus, aber dann haben wir zwei Probleme festgestellt.
Vielleicht kann ja jemand was dazu sagen.
1. Wenn der 2019 Server eine Mail versenden will, bei dem der MX Record eine v4 und eine v6 Adresse hat, scheint es so als wenn er immer zuerst einen Tag lang versucht die Mail über v6 zu verschicken, was aber nicht klappt.
Was macht man denn da am besten? v6 auf dem 2019 abschalten?
2. Unser SAP System kann keine Mails über den 2019 verschicken.
Angeblich hat MS mit dem CU1 von 2019 einen Rückgabewert im EWS geändert, mit dem SAP nicht umgehen kann.
Hat da jemand möglicherweise Infos drüber? Sonst müsste ich bei SAP dazu mal einen Fall aufmachen.
Gruß
Florian
Hi, danke für deinen tollen Block.
Ich habe eine DAG mit Exchange 2016 am laufen, und habe nur einen 2019 hinzu installiert. Dieser wurde noch nicht konfiguriert.
Teileweise können die User Ihr Outlook nicht mehr öffnen, da er aus welchen Grund auch immer über den 2019 connecten will.
Ist das bekannt? gibt es dazu eine Lösung, denn im Netz finde ich nichts.
Hallo Daniel,
da der Exchange 2019 Server nach der Installation auf Autodiscover Anfragen antwortet, muss der Exchange 2019 Server direkt nach der Installation konfiguriert werden. Insbesondere die Konfiguration der URLs und der Zertifikate ist wichtig.
Gruß,
Frank
Danke für die Info, hat dann geklappt
Sehr schön beschrieben. Echt top. Da freue ich mich schon auf meine erste MSX16 zu 19 Migration am Freitag. Deine Anleitungen sind immer echt super. Bei allen MSX10 nach 16 Migrationen war deine Anleitung immer mein roter Faden.
Mfg Archy
Schön das du die Client Access Rules ansprichst!