In the last part of the article series "Migration from Exchange 2016 to Exchange 2019", the uninstallation of Exchange 2016 is prepared and the migration completed.
The small Troubleshooting section is dedicated to the most common cause of failed or stopped MoveRequests. Problems can always occur during migrations that could not be ruled out beforehand. The causes can be manifold, so I cannot go into all eventualities here.
Troubleshooting
Before Exchange 2016 can be uninstalled, all mailboxes must be moved from the Exchange 2016 database to the Exchange 2019 database. In part 3 of this article series, MoveRequests were used for this purpose.
However, it often happens that some MoveRequests have the status "Suspended" or "Failed" and therefore the mailbox is not moved.
The status of the MoveRequests can be checked with the following command:
Get-MoveRequest
In most cases, the MoveRequests are not completed because there are defective elements within the mailboxes. Here it usually helps to raise the corresponding limit of tolerable errors. With the following command, 50 faulty elements can be permitted for existing MoveRequests:
Get-MoveRequest | Set-MoveRequest -BadItemLimit 50
The MoveRequests can then be continued:
Get-MoveRequest | Resume-MoveRequest
As already mentioned, there may also be other causes for incorrect move requests. The following command provides further information for troubleshooting:
Get-MoveRequest | Get-MoveRequestStatistics | fl
There is also another article here that can help failed MoveRequests:
As already mentioned at the beginning, there are many causes for failed MoveRequests. You are welcome to leave further causes and solutions as comments. If there are enough tips, I will be happy to include them as a separate article.
Once all MoveRequests have been successfully completed and have the status "Completed", the MoveRequests can be deleted:
Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest
To ensure that no problems occur during uninstallation, a little tidying up should be done.
Preparing to clean up and uninstall
To ensure that the uninstallation of Exchange 2016 runs as smoothly as possible, a few clean-up tasks should be carried out before the uninstallation.
While I was tidying up, for example, I noticed that I had forgotten to move the AuditLog mailbox. I didn't do this in part 3, so I'll do it now. Here are the already known commands for displaying and moving:
get-mailbox -Database DB2016 -AuditLog
get-mailbox -Database DB2016 -AuditLog | New-MoveRequest -TargetDatabase DB2019
Get-MoveRequest
Get-MoveRequest | where {$_.status -match "Completed"} | Remove-MoveRequest
Now that the AuditLog mailbox has also been moved, there should no longer be any mailboxes stored in the old Exchange 2016 database. The common mailbox types can be queried with the following commands:
get-mailbox -Database DB2016 get-mailbox -Database DB2016 -Arbitration get-mailbox -Database DB2016 -Archive get-mailbox -Database DB2016 -PublicFolder get-mailbox -Database DB2016 -AuditLog
There should now also be no more MoveRequests. If there are still MoveRequests at this point, these must first be completed and deleted (see Troubleshooting section). The following command can be used to check whether MoveRequests still exist:
Get-MoveRequest
If there are no more mailboxes in the Exchange 2016 database and no more MoveRequests are displayed, the Exchange 2016 server can be removed from the scope definition of the Send Connector:
There should now be no problems during uninstallation.
Uninstallation
Exchange 2016 can be uninstalled from the Control Panel via "Programs and Features":
Note: Before Exchange 2016 is uninstalled, any existing AntiVirus/AntiSPAM software for Exchange should be uninstalled. These programs often prevent Exchange from being uninstalled successfully.
After clicking on "Next", the uninstallation routine checks once again whether the uninstallation can be carried out:
In this case, everything is OK and the uninstallation can be started:
Uninstalling takes a few minutes:
Exchange 2016 has been successfully uninstalled and a final restart is requested:
This completes the migration to Exchange 2019. There are two further optional steps that can now be carried out.
Optional: Remove server from domain
If the Exchange 2016 server is no longer running any other services, the server can now be removed from AD and shut down. The Windows installation should no longer be used for other services. The computer account of the old Exchange 2016 server should also be deleted (if it still exists).
Note: The deinstallation routine does not remove the old database files and logs, so if the operating system of the old Exchange Server is still in operation (possibly due to other services), the database and logs should be deleted manually:
If the server hardware is to continue to be used, a clean reinstallation of the operating system is recommended.
Optional: Client Access Rules (Restrict Exchange Admin Center)
The "Client Access Rules" are a new Exchange 2019 feature that can be used to restrict access to the Exchange Admin Center (EAC), among other things.
In the test environment described here, there is a NAT entry which forwards port 443 to the Exchange 2019 server:
This NAT entry publishes Exchange 2019 on the Internet, meaning that protocols such as ActiveSync and MAPIoverHTTP can be used from the Internet. At the same time, it also makes the Exchange Admin Center (EAC) accessible from the Internet. Administrative interfaces such as EAC, which are directly accessible on the Internet, always represent a potential security risk. Especially if, as in this test environment, no web application firewall or other protective measures are used.
To ensure that administrative interfaces such as the EAC cannot be accessed directly from the Internet, access can be restricted, for example to the internal network or a dedicated management network.
For example, the following commands can be used to restrict access to the RemotePowerShell and EAC to the internal network 192.168.200.0/24:
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
Access to EAC and PowerShell from computers outside the 192.168.200.0/24 subnet is therefore no longer possible. Of course, care must be taken here so that you do not lock yourself out.
A detailed article on the Client Access Rules will follow.
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!