Exchange 2013: Stolperstein beim Update einer alten Version auf das aktuelle CU

In einem früheren Artikel hatte ich bereits darauf hingewiesen, dass es wichtig ist, die NET Abhängigkeiten von Exchange zu berücksichtigen. In der Theorie sind alle Exchange Updates kumulativ, sprich das aktuelle CU enthält die kompletten Installationsdateien sowie alle vorangegangen Patches. Mit dem CU lässt sich also eine Neuinstallation durchführen, sowie eine vorhandene Installation aktualisieren. In der Theorie lässt sich somit auch beispielsweise eine Exchange 2013 RTM Installation direkt auf das aktuelle CU aktualisieren. Dies ist aber eben nur in der Theorie der Fall, denn es gibt die Abhängigkeiten zur eingesetzten und unterstützen NET Framework Version.

Michel de Rooij hat dazu eine schöne Grafik für die Abhängigkeiten der NET Framework Versionen zur Exchange Version erstellt, in der deutlich wird, dass beim der Aktualisierung einer alten Exchange 2013 Installation mitunter Zwischenschritte nötig sind:

In der Grafik wird das Problem schon deutlich: Eine Exchange 2013 Installation mit CU4, kann nicht direkt zu CU19 aktualisiert werden, denn CU4 unterstützt kein NET Framework 4.6.2. NET 4.6.2 ist aber wiederum Voraussetzung für CU19.

Die Installation muss also zunächst auf CU15 aktualisiert werden, danach kann die NET Framework auf NET 4.6.2 aktualisiert werden und erst jetzt kann Exchange 2013 CU19 installiert werden. Der nächste Zwischenschritt steht dann auch schon wieder in den Startlöchern, denn für zukünftige CUs wird NET Framework 4.7.1 Voraussetzung sein (Diese Abhängigkeiten gibt es auch bei Exchange 2016).

Soweit erst einmal zur Problematik, es muss halt aktuell der Zwischenschritt über CU15 gegangen werden, um eine alte Exchange 2013 Installation auf den aktuellen Stand zu bringen. Der Stolperstein liegt eher an einer ganz anderen Stelle:

Woher das CU15 nehmen?

Microsoft bietet das CU15 für Exchange 2013 nicht mehr direkt als Download an, der Link zum alten CU15 Download führt ins Leere und die Update Seite enthält lediglich den Hinweis, dass es bereits ein neueres Update gibt. Im Technet gibt es dazu bereits einen ernüchternden Thread:

Die Antwort ist allerdings erst einmal wenig hilfreich: Contact Microsoft…

Wer das CU15 noch irgendwo auf der Platte hat, sollte es aktuell lieber nicht löschen. Man könnte es ja noch einmal gebrauchen…

Ich habe mir erlaubt eine Anfrage an MS zu stellen, um zu erfahren ob es wirklich nötig ist den Support zu kontaktieren um einen Downloadlink zum CU15 zu erhalten. Sobald ich eine Antwort habe, werde ich den Artikel aktualisieren.

Update 02.01.2018

Hier zunächst mal die Antwort vom MS Support auf meine Anfrage. Einen Downloadlink für das CU15 habe ich nicht bekommen, dafür aber einen Workaround. Der Case ist allerdings noch nicht geschlossen und ich werde noch einmal detaillierter nachfragen und den Artikel hier aktualisieren.

Anwtort Support

Update 04.01.2018

Ich habe den empfohlenen Workaround einmal ausprobiert. Ich hatte allerdings nur einen Exchange 2013 Server ohne DAG zur Hand. Ich bin dabei wie folgt vorgegangen:

  1. Alle Exchange Dienste gestoppt und auf Starttyp „Deaktiviert“ gestellt
  2. NET Framework 4.6.2 installiert
  3. Server neu gestartet
  4. Alle Exchange Dienste auf Starttyp „Automatisch“ gestellt, aber beendet gelassen
  5. CU19 installiert
  6. Server neu gestartet

Der einzelne Exchange 2013 Server ist sauber gestartet und scheint augenscheinlich normal zu funktionieren. Wer eine Exchange 2013 DAG betreibt, muss die DAG vorher in den Maintenance Modus versetzen (Performing maintenance on DAG members)

Nicht vergessen die Exchange Dienste nach dem ersten Neustart wieder auf Starttyp „Automatisch“ zu stellen, sonst schlägt die Installation von CU19 fehl:

Update 26.01.2018

Jetzt ist die oben beschriebene Methode auch als Hinweis im TechNet verfügbar:

Trotzdem sollte darauf geachtet werden, dass die Exchange Server mit aktuellen Updates versehen werden.

30 Replies to “Exchange 2013: Stolperstein beim Update einer alten Version auf das aktuelle CU”

  1. Geht ein exchange 2013 „älter CU15“ denn „kaputt“ wenn man ihn erst Dotnet 4.7 und anschließend den cu19 verpasst…?

  2. Nachtrag:
    … Oder ist das einfach nur nicht supported?

    Und wenn ich das dann so mache, habe ich im Endergebnis wieder ein unterstütztes System, oder ist es out of support weil vorübergehend die supportete Umgebung verlassen wurde?

  3. Hi,

    laut diverser Aussagen von MVPs und MS Support Mitarbeitern ist es sogar noch „schlimmer“, du sollst maximal 2 CUs auslassen.
    Bedeutet von CU4 gehst du über die 7, 10, 13, 16 auf die 19…

    Ich habe bisher noch nicht hinterfragt, ob Sie es wirklich auf dem System / im AD auslesen können, welche Versionen installiert waren.

    Bei den 2 Fällen, wo wir es hatten, Dienstleisterwechsel, haben wir einfach eine neue VM installiert und die Daten migriert.

    Gruß
    J

  4. Hallo Jann,

    Dann stellt sich ja noch viel mehr die Frage danach woher die alten CUs nehmen wenn nicht stehlen…?

  5. Eine Warnung möchte ich auch für EX2016-Sicherheitsupdate CU7 abgeben. Ich bin nicht sicher, ob es ebenfalls an der NET_Version liegt, aber an meinem letzten Arbeitstag vor dem Fest stand bei uns dieses update in der Pipeline, dass entsprechend der Konfiguration auf das Ende der reglulären Arbeitszeit wartete.
    Sicher keine glückliche Konfiguration bei zwei EX2016 in einer DAG, aber wer rechnet schon damit, dass in Folge beide EX2016 nicht mehr starteten, alle Dienste deaktiviert waren und sich die DAG nicht mehr in Betrieb nehmen ließ. Beide Server meldeten (nachdem ich die Dienste manuell wieder aktiviert hatte), dass sie bereits Mitglied einer DAG wären, die aber nicht mehr angezeigt wurden, die Rollendienste (Cluster) ließen sich nicht deinstallieren noch konnte eine neue DAG erzeugt werden. Selbst die Wiederherstellung eines Servers aus dem Fullbackup brachte keine Verbesserung, stattdessen liefen die Fehlerlogs mit Replikationswarnungen etc. über. Wie zum Glück verlinkte Frank einige Tage später das CU8, weil CU7 mit dem bekannten Hinweis auf eine fehlerhafte vergangene Installation jede weitere Ausführung verweigerte.
    Die Server sind jetzt neu… Weihnachten war kurz… Man lernt nie aus.

  6. @Lars Dittmar: Hallo Lars, da hast Du aber voll rein gelangt. Das tut mir leid! Kleiner Tipp von Admin zu Admin: Vor den Feiertagen gibt es KEINE Updates! NIE! ;-)

  7. Die gleiche Problematik gab es bei CU18 auch schon. Meiner Meinung ist es unproblematisch. Man installiert die neue .Net Version ja nur für das Update. Danach wird die alte Programmversion ohnehin direkt deinstalliert. Klar kommt es hier und da mal zu Fehlern während eines Updates. Diese hatten bei mir aber bislang nichts mit der .Net Version zu tun.

  8. Dasselbe Problem habe ich gerade mit dem CU4 für Exchange Server 2016. Auch hier sollte mit Blick auf die .NET Supportmatrix erst CU4 mit .NET 4.5.2 installiert werden. Dann .NET auf 4.6.2 aktualisiert werden, um dann CU8 und danach .NET 4.7.1 installiert werden. Aber woher das CU4 kriegen?

  9. @Alexander Straub
    CU4 für Exchange 2016 hätte ich noch rumliegen, weil ich genau den selben Upgradepfad gemacht habe, wie Du ihn beschreibst.
    Kann das gerne auf ondrive hochladen, wenn gewünscht.

  10. Hallo zusammen

    Falls noch jemand auf der Suche nach „Exchange2013-x64-cu15.exe“ und „UMLanguagePack.de-DE.exe“ ist, könnte ich ebenfalls helfen ;-)

  11. Hallo Patric,

    ich bräuchte ebenso wie Gunther das Ex2013 CU15 sowie das UMLanguagePack.
    Könntest du dies bereitstellen?

    Gruß Sebastian

  12. Hallo,

    da ich noch auf Ex2013CU14 bin, benötige ich ebenfalls den Zwischenschritt auf CU 15 und das UMLanguagePack.

    @Patric K: Hast du das noch rumliegen, und kannst es mir irgendwo bereit stellen?

  13. Hatte das Problem vor Weihnachten auch. Exchange 2016 CU7 Installation, Neustart – alle Dienste deaktiviert, manuelles Aktivieren half nicht, MS Support kontaktiert, Exchange Recovery durchführen, also neue VM erstellt, Recovery Installation durchgeführt mit CU 6 – läuft! Snapshot erstellt, CU7 erneut installiert, Dienste starten zwar, ECP funktionierte jedoch nicht, Support nochmal kontaktiert – Antwort: „bitte instabileren Sie diese Update nicht mehr.
    Wie habe schon viele identische Fälle und wir habe es auf höhere Stufe eskaliert so dass es gefixt wird.“
    Snapshot wiederhergestellt und alles war wieder gut. Jetzt tauch dieses Update nur permanent auf Server 2016 in den Updates auf und ich kann es nicht abwählen :-(

    Wer das Exchange 2013 CU15 haben möchte: Dieser OneDrive Link funktionierte am 12.1.18 noch: „Link entfernt“

  14. Ein „Zwischenschritt“ über CU15 (oder ein anderes CU) ist nicht notwendig. Der in diesem Post beschriebene „workaround“ klappt auch mit Exchange 2016. Ich kann nur davon abraten Software aus anderen Quellen als dem Microsoft Download Center zu deployen.
    Wer nicht update kann oder will, sollte auf Nummer sicher gehen und einen weiteren Server mit supportetem, aktuellen CU deployen und Datenbanken/Mailboxes und Client-Access umzustellen.

    Ralf

  15. Das ist natürlich richtig, Ralf und war ein Fehler meinerseits eine „unbekannte“ Quelle anzugeben. Ich bitte um Verzeihung.
    Im Moment habe ich eher das Problem, das Windows Server 2016 das CU 7 Update für den Exchange 2016 in seiner Update Liste hat und ich den Server nicht neu starten kann, weil er sonst das Update automatisch installiert. Ich hoffe auf die Möglichkeit das aktuelle CU 8 zu installieren und das der Fehler im CU 8 nicht mehr vorhanden ist und Windows dann auch das CU 7 aus den Updates automatisch wieder entfernt.
    Habt jemand evtl. einen alternativen Vorschlag?

  16. @Adrian: ja, 4.7.0 sollte zu keinem Zeitpunkt verwendet werden. Exchange Dienste stoppen, 4.7.1 installieren, auf CU19 updaten. Also entsprechend den Schritten die Frank oben im Screenshot hat folgen.

  17. Hallo,
    wir stehen kurz davor zu der Thematik bei Microsoft einen Case zu eröffnen und dann bin ich über diesen Blog-Eintrag gestolpert. Eigentlich habe ich den RSS-Feed abonniert, aber wohl über die Feiertage diesen Artikel überlesen.

    @Frank: Gibt es bezüglich dem Supportcall bei Microsoft noch weitere Rückmeldungen, oder ist der Workaround mit den sechs Schritten die einzige fachliche Antwort gewesen?

    Danke
    Thomas

  18. Hallo Thomas,
    meine Anfrage an MS wurde inzwischen geschlossen. Das Update einer Testumgebung von Exchange 2013 RTM auf das aktuelle CU funktionierte mit der oben beschriebenen Methode problemlos.
    Gruß, Frank

  19. Hallo Zusammen,
    wir haben das Update wie beschrieben gemacht.
    Wir sind von Exchange 2016 CU2 direkt auf CU8 inkl .NET 4.7.1 Upgrade. Hat ohne Probleme funktioniert.
    Nur sollte man daran denken bevor das Exchange CU8 Update gestartet wird eventuell vorherige Änderung am Start-typ der Exchange Services wieder rückgängig zu machen, bzw. diese auf „automatisch“ zu stellen. Exchange CU merkt sich den Start-Typ der Services in der ‚C:\ExchangeSetupLogs\ServiceStartupMode.xml‘ und setzt diesen Starttyp mehrmals während der Installationsphase. Sollten dann die Services auf „disabled“ stehen können diese während des Updates nicht gestartet werden und das Update bricht mit einer Fehlermeldung ab. Sollte der Fehler mal auftreten, kann die XML Datei editiert und angepasst werden.

  20. Guten Morgen zusammen,
    ich möchte am Samstag das Update von Exchange 2013 CU 13 auf das CU 19 durchführen. Meine Frage betrifft nun die richtige Reihenfolge für das Stoppen der Exchange-Dienst. Leider habe ich nichts Genaues bei Onkel Google gefunden.(Nur die alten Versionen)
    Vielleicht ist ja jemand so nett und kann mir Auskunft geben, in welcher Reihenfolge die Dienste sauber gestoppt und nachher wieder gestartet werden müssen, damit das Update auch funktioniert.
    Vielen Dank im Voraus

  21. Hi,

    ich habe auf dem Server 2008 R2, Exchange 2013 CU6 mit .NET 4.7.1 laufen ( Version 461310 ).

    Kann man damit direkt auf die CU19 gehen? Mit der Methode von „Update 04.01.2018“?

  22. Wenn ich das richtig in Erinnerung habe, ist das nicht entscheidend, in welcher Reihenfolge die Dienste gestoppt/gestartet werden.

  23. @Eugen, ja.
    Mittlerweile gibt es folgende offizielle Aussage:
    „When upgrading Exchange from an unsupported CU to the current CU and no intermediate CUs are available, you should upgrade to the latest version of .NET that’s supported by Exchange first and then immediately upgrade to the current CU. This method doesn’t replace the need to keep your Exchange servers up to date and on the latest, supported, CU.
    Microsoft makes no claim that an upgrade failure will not occur using this method, which may result in the need to contact Microsoft Support Services.“

    hier: https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx
    Ich hoffe das bringt etwas mehr Klarheit ins Thema.

  24. Hallo Zusammen,
    dank Frank‘s super Anleitung habe ich heute das Update von CU 13 auf CU 19 ohne Probleme durchführen können. Danke auch an die vielen guten Kommentare.
    Das Forum hier ist schon Klasse. Jetzt muss es mir nur noch gelingen, Outlook 2016 von außen an den Exchange Server anzubinden. Da haben wir so viele Probleme. Mit Outlook 2013 funktioniert es ohne Probleme.
    Vielleicht hat ja noch der ein oder andere noch einen Tipp parat. Ich bin gerade noch Franks neue Autodiscover Anleitung am Studieren. Vielleicht klappt‘s ja. Ich werde Euch auf dem Laufenden halten.
    Euch allen ein schönes Wochenende

  25. Wir hatten das Problem, dass wir den Exchange 2013 CU13 direkt auf CU 19 updaten wollten. Nach dem Setup Start begann das Update Schritt 1/17 und deaktivierte alle Dienste. Nach 20-30 Minuten gab es dann eine Fehlermeldung. Dienste waren alle deaktiviert. Manuelles Aktivieren und Neustarten des Servers half nicht. Exchange wurde per Snapshot zurückgesetzt. Outlook funktionierte dennoch nicht. ServerComponentState war alles inaktiv. Nach Aktivierung aller ComponentStates funktionierte es weiterhin hin. Erst als der DomainController ebenfalls zurückgesetzt wurde funktionierte wieder alles. Wir haben uns an die 6 Punkteliste im Beitrag gehalten, Virenscanner deaktiviert und es hat dennoch nicht funktioniert. Die Vorabprüfung war erfolgreich. Hatte jemand ähnliche Probleme dass bereits bei Schritt 1 Fehler auftraten?

  26. Hallo zusammen.
    Wir haben bei uns intern am Wochenende unseren Exchange 2013 CU7 nach deinem beschriebenen Weg auf CU19 aktualisiert. Alles hat einwandfrei funktioniert. Ich habe zudem vorgängig manuell das Schema aktualisiert und danach mittels dcdiag überprüft, ob die Replikation auf sämtliche DCs erfolgreich war. Danach habe ich das CU19 gestartet und alles funktionierte einwandfrei :) .
    Vielen Dank für den grossartigen Blog!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.