none
Exchange 2013 Update CU8 -> CU21 RRS feed

  • Frage

  • Hallo,

    aktuell haben wir das Problem das wir einen Exchange 2013 mit CU8 auf die aktuelle Version CU21 bringen möchten.

    Unser Plan war von CU8 auf CU14 dann auf CU18 und dann auf CU21 zu gehen. Auf dem System ist schon .NET Framework 4.7.2 installiert.

    Jetzt haben wir bei dem Schritt CU8 -> CU14 aber schon eine Fehlermeldung erhalten:

    ---

    Fehler:
    Der folgende Fehler wurde generiert, als "$error.Clear(); 
              $dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, "bin", "DependentAssemblyGenerator.exe");
              $exchangeBinPath  = [System.IO.Path]::Combine($RoleInstallPath, "bin");
              $clientAccessPath = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess");
              $sharedWebConfig  = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess", "SharedWebConfig.config");
    
              $a = &"$dependentAssemblyGeneratorExePath" -exchangePath "$exchangeBinPath" -exchangePath "$clientAccessPath" -configFile "$sharedWebConfig";
              $a | % { if ($_.Length > 0) { Write-ExchangeSetupLog -Info "$_.ToString()" } }
              Start-SetupProcess -Name "iisreset" -Args "/timeout:120"
            " ausgeführt wurde: "System.Management.Automation.RemoteException".
    
    Fehler:
    Der folgende Fehler wurde generiert, als "$error.Clear(); 
              $dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, "bin", "DependentAssemblyGenerator.exe");
              $exchangeBinPath  = [System.IO.Path]::Combine($RoleInstallPath, "bin");
              $clientAccessPath = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess");
              $sharedWebConfig  = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess", "SharedWebConfig.config");
    
              $a = &"$dependentAssemblyGeneratorExePath" -exchangePath "$exchangeBinPath" -exchangePath "$clientAccessPath" -configFile "$sharedWebConfig";
              $a | % { if ($_.Length > 0) { Write-ExchangeSetupLog -Info "$_.ToString()" } }
              Start-SetupProcess -Name "iisreset" -Args "/timeout:120"
            " ausgeführt wurde: "System.Management.Automation.RemoteException: Unbehandelte Ausnahme:".
    
    Fehler:
    Der folgende Fehler wurde generiert, als "$error.Clear(); 
              $dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, "bin", "DependentAssemblyGenerator.exe");
              $exchangeBinPath  = [System.IO.Path]::Combine($RoleInstallPath, "bin");
              $clientAccessPath = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess");
              $sharedWebConfig  = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess", "SharedWebConfig.config");
    
              $a = &"$dependentAssemblyGeneratorExePath" -exchangePath "$exchangeBinPath" -exchangePath "$clientAccessPath" -configFile "$sharedWebConfig";
              $a | % { if ($_.Length > 0) { Write-ExchangeSetupLog -Info "$_.ToString()" } }
              Start-SetupProcess -Name "iisreset" -Args "/timeout:120"
            " ausgeführt wurde: "System.Management.Automation.RemoteException:  ".
    
    Fehler:
    Der folgende Fehler wurde generiert, als "$error.Clear(); 
              $dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, "bin", "DependentAssemblyGenerator.exe");
              $exchangeBinPath  = [System.IO.Path]::Combine($RoleInstallPath, "bin");
              $clientAccessPath = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess");
              $sharedWebConfig  = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess", "SharedWebConfig.config");
    
              $a = &"$dependentAssemblyGeneratorExePath" -exchangePath "$exchangeBinPath" -exchangePath "$clientAccessPath" -configFile "$sharedWebConfig";
              $a | % { if ($_.Length > 0) { Write-ExchangeSetupLog -Info "$_.ToString()" } }
              Start-SetupProcess -Name "iisreset" -Args "/timeout:120"
            " ausgeführt wurde: "System.Management.Automation.RemoteException: System.UnauthorizedAccessException: Der Zugriff auf den Pfad "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\SharedWebConfig.config" wurde verweigert.
       bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       bei System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
       bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
       bei System.Xml.XmlDocument.Save(String filename)
       bei Microsoft.Exchange.Management.DependentAssemblyGenerator.UpdateConfigFile(String configFilePath, IList`1 exchangeAssemblies, Int32& numAssembliesAdded)
       bei Microsoft.Exchange.Management.DependentAssemblyGenerator.Main(String[] args)".
    
    Fehler:
    Der folgende Fehler wurde generiert, als "$error.Clear(); 
              $dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, "bin", "DependentAssemblyGenerator.exe");
              $exchangeBinPath  = [System.IO.Path]::Combine($RoleInstallPath, "bin");
              $clientAccessPath = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess");
              $sharedWebConfig  = [System.IO.Path]::Combine($RoleInstallPath, "ClientAccess", "SharedWebConfig.config");
    
              $a = &"$dependentAssemblyGeneratorExePath" -exchangePath "$exchangeBinPath" -exchangePath "$clientAccessPath" -configFile "$sharedWebConfig";
              $a | % { if ($_.Length > 0) { Write-ExchangeSetupLog -Info "$_.ToString()" } }
              Start-SetupProcess -Name "iisreset" -Args "/timeout:120"
            " ausgeführt wurde: "System.Management.Automation.RemoteException: 
    ".
    

    ---

    Daraufhin habe ich die Schritte aus folgendem Link durchgeführt:

    https://social.technet.microsoft.com/Forums/en-US/a1c5c0f6-73db-4845-98b8-7a3c3031d3ed/exchange-2013-cu15-cas-upgrade-fails?forum=exchangesvrdeploy

    Allerdings schlägt der Befehl auch fehl mit folgender Meldung:

    PS C:\Program Files\Microsoft\Exchange Server\V15\Bin> DependentAssemblyGenerator.exe -exchangePath "%ExchangeInstallPat
    h%\bin" -exchangePath "%ExchangeInstallPath%\ClientAccess" -configFile "%ExchangeInstallPath%\ClientAccess\SharedWebConf
    ig.config"

    02.08.2018 13:30:25 - Begin Dependent Assembly Generation.

    02.08.2018 13:30:25 - Recursing %ExchangeInstallPath%\bin for DLLs.

    Unbehandelte Ausnahme: System.IO.DirectoryNotFoundException: Ein Teil des Pfades "C:\Program Files\Microsoft\Exchange Se
    rver\V15\Bin\%ExchangeInstallPath%\bin" konnte nicht gefunden werden.
       bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       bei System.IO.FileSystemEnumerableIterator`1.CommonInit()
       bei System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, Search
    Option searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost)
       bei System.IO.Directory.EnumerateFiles(String path, String searchPattern, SearchOption searchOption)
       bei Microsoft.Exchange.Management.DependentAssemblyGenerator.GetExchangeAssemblies(String exchangeInstallPath, IList`
    1 assembliesToAddToWebConfig)
       bei Microsoft.Exchange.Management.DependentAssemblyGenerator.Main(String[] args)

    Wenn ich %ExchangeInstallPath% durch den richtigen Pfad ersetze, dann läuft das Script ohne Probleme durch.

    Prüfen der Umgebungsvariable zeigt aber das diese eigentlich richtig ist:

    PS C:\Program Files\Microsoft\Exchange Server\V15\Bin> $env:exchangeinstallpath
    C:\Program Files\Microsoft\Exchange Server\V15\

    Das mag vielleicht auch an der .Net Version liegen?

    Eventuell macht es ja auch gar keinen Sinn erst auf CU14 - CU18 zu gehen um dann auf CU21 zu gehen.

    Wir sind für weitere Ideen offen...


    Jörg

    Freitag, 3. August 2018 06:35

Alle Antworten

  • Vor den Updates erst mal das Framework 4.7 wieder runterschmeißen und auf Aussetzen stellen!!!

    Es gibt entsprechende Hinweise, dass Exchange 2013 und älter nicht für das Framework 4.7 freigegeben ist.
    Solange ihr also auf der Version 2013 bleibt, dürft ihr das Framework nicht einsetzen.

    Willkommen zurück in der (.Net)DLL-Hölle.

    Freitag, 3. August 2018 08:17
  • Hallo,

    erstmal danke für die Antwort, allerdings wird doch .Net 4.7.1 ab CU19 unterstützt? Also nur .Net 4.7.2 "ausblenden"?

    Desweiteren hatte ich schon Exchange 2013 Server mit CU14 wo auch .net 4.7.1 installiert war, und wir dort direkt das Update auf CU20 gemacht haben. Glücklicherweise ohne keine Probleme.

    Deswegen noch einmal die Frage: Kann man von der CU8 direkt auf die CU21 gehen, oder sollte man Zwischenschritte machen?

    Die nächste Frage wäre dann ob bei dem Update zu CU21 nicht auch der vorher genannte Fehler kommt?


    Jörg

    Freitag, 3. August 2018 09:57
  • Hallo,

    erstmal danke für die Antwort, allerdings wird doch .Net 4.7.1 ab CU19 unterstützt? Also nur .Net 4.7.2 "ausblenden"?

    Desweiteren hatte ich schon Exchange 2013 Server mit CU14 wo auch .net 4.7.1 installiert war, und wir dort direkt das Update auf CU20 gemacht haben. Glücklicherweise ohne keine Probleme.

    Deswegen noch einmal die Frage: Kann man von der CU8 direkt auf die CU21 gehen, oder sollte man Zwischenschritte machen?

    Die nächste Frage wäre dann ob bei dem Update zu CU21 nicht auch der vorher genannte Fehler kommt?


    Jörg

    Moin,

    Ja, man kann direkt auf das CU21 gehen - aber alles neuer als .NET 4.7.1 ist derzeit mit keinem Exchange supportet.

    Musst halt für den Fall der Fälle ein gutes Backup haben.

    Wenn mit CU14 auf .NET 4.7.1 warst und alles geklappt hat Zufall.
    Der Offizielle Support bei 2013 kam mit dem März-Update, sprich CU20 bei 2013.
    https://blogs.technet.microsoft.com/exchange/2018/03/20/released-march-2018-quarterly-exchange-updates/

    Mir ist immer wieder ein Rätsel, wie man so wichtige Server nicht auf Stand hält.

    MS sagt in so einem Fall bei einem Case - erst mal patchen, dann sehen wir weiter.

    Nachtrag - du musst nicht nur das .NET 4.7.2 deinstallieren, sondern das .NET 4.7.1 muss noch mal "drüber" - das zerlegt dir einige Assemblies…

    Und dann verbieten.


    Gruß Norbert


    Freitag, 3. August 2018 14:15
    Moderator
  • Mit Einführung von .Net war ja eigentlich das Ende der DLL-Hölle eingeleutet, die nun mit .Net 4.0 (bzw. bis 4.5 war noch alles kompatibel) wieder fröhliche Urstände feiert.

    Bis 4.0 wurde jede .Net-Hauptversion (1.1, 2.0, 3.0, 3.5, 4.0) in einem eigenen Verzeichnis installiert. Somit konnte jede Anwendung mit ihrer Net-Runtime ohne Probleme laufen.

    Seit 4.5 wird aber alles an .Net-Versionen in das 4.0 Verzeichnis reingehauen.
    Was unweigerlich bei vielen Anwendungen zu z.T. massiven Problemen geführt hat und immer noch führt.

    So manche Software hat u.U. keine Hersteller mehr, man ist darauf angewiesen, es gibt keine Alternative (mehr oder noch nicht) und Microsoft zerschießt diese durch einen .Net-Update?

    Da traut man sich ja kaum, für 4.x zu entwickeln und bleibt lieber bei der stabilen 3.5!
    Und dann bekommt man um die Ohren geknallt, warum man seine Server nicht aktuell hält oder noch besser ständig neue Versionen einführt und sein Geld Microsoft in den Rachen schmeißt?

    Wenn Microsoft sich an seine Richtline in .Net bzgl. der Vermeidung der DLL-Hölle halten würde, könnte man seine Server auch aktuell halten.
    Aber das schlimmste was einem da passieren kann, dass der Server einen Update benötigt, der zwingend die Runtime 4.7.x benötigt und dann?
    Kommt dann auch eine Antwort: erst mal Patchen dann sehen wir weiter, wobei das Patch sich dann gar nicht erst einspielen läst? Und wann man dann die Runtime zurückdreht, läuft auf einmal der ganze Server nicht mehr....

    So langsam artet das Verhalten Microsofts zur Katastrophe aus.
    Was denken die Leute dort eigentlich, wie viel Geld man für seine IT vorhalten muss?
    Manche Dinge übersteigen bei weitem meinen Gewinn.

    Freitag, 3. August 2018 14:37