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.
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:
- Alle Exchange Dienste gestoppt und auf Starttyp „Deaktiviert“ gestellt
- NET Framework 4.6.2 installiert
- Server neu gestartet
- Alle Exchange Dienste auf Starttyp „Automatisch“ gestellt, aber beendet gelassen
- CU19 installiert
- 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.
Moin,
ich habe gerade einen Exchange 2013 CU3 auf CU23 direkt geupdatet (bei einem Kunden).
.NET 4.7.2 war wohl schon länger auf dem Server installiert wegen anderer Software (war noch ein Bare-Metal-Server der als eierlegende Wollmilchsau genutzt wird).
Ich habe – Sicherheitshalber – vorher die VCredist 2012 und 2013 in 32 und 64 Bit installiert, das Schema-Update vorher von Hand ausgeführt (wie von Franky in seinem Artikel über CU unter 2016 installieren beschrieben), die Dienste vom Exchange, von ScanMail und TrendMicro angehalten und dann die Setup.exe gestartet.
Er hat wohl um die 75 Minuten gerödelt, Setup lief fehlerfrei durch. Alles was ich testen konnte funktioniert einwandfrei.
Nun kann ich morgen mit der Migration auf Exchange 2019 beginnen.
Hallo zusammen,
aufgrund der Sicherheitslücke bekam ich einige Exchange 2013 Server neu hinzu und musste diese dringendst auf CU23 anheben. Hat einwandfrei bei allen funktioniert wie oben in der Anleitung beschrieben!
Vielen Dank.
Grüße,
Florian
Hi,
ich habe gerade ein Exchange2016 von CU 4 auf CU 19 Update gemacht, klappte wunderbar.
Ich bin wie oben beschrieben vorgegangen:
Exchange Dienste beenden und deaktivieren
Net4.8 installiert.
Neustart
Dienste auf automatisch gestellt.
Visual C++2013 x64 installiert
CU19.iso gemountet
Doppelklick auf setup.exe
Dauerte ca 80 Minuten.
Neustart und alles funktioniert.
Vielen Dank!
Hi,
I have just done an update for Exchange 2013 SP1 to CU23 and the security update needed for the vulnerability found. Used these steps and it worked a charm, thanks for submitting.
Zwar schon ein älterer Thread. Update von Exchange 2013 CU11 auf CU23 wegen der aktuellen Sicherheitswarnung hat perfekt nach obiger Anleitung funktioniert. Exchange 2013 CU23 versucht zwar auch bei der Installation die Exchange-Dienste zu stoppen; aber es ist auf alle Fälle sicherer es wie im Startpost beschrieben vor dem Update selbst zu machen.
Hallo,
extra angemeldet um meinen Dank auzusprechen. Diese Anleitung hier hat mir meinen Hintern gerettet :-)
Eben fertig geworden, von Exchange Server 2013 SP1 (15.0.847.32) auf Exchange Server 2013 CU23 (15.0.1497.2) installiert aufServer 2012 R2.
Bei mir war .NET Framework 4.8 schon installiert (ich vermute das AVG der Schuldige war), der Update Prozess ist ohne weiteres durchgelaufen, neu gestartet, Dienste kontrolliert, OWA und Outlook gecheckt, funktioniert alles. Wunderbar!.
Ach ja, um die Dienste nicht alle einzeln zu beenden und zu deaktivieren habe ich den Tipp hier benutzt (hoffe ich darf einen Link hier Posten):
https://just-it-stuff.de/exchange-server/alle-exchange-dienste-ueber-powershell-stoppen-und-deaktivieren/
Danke nochmal für die Arbeit die hier investiert wird!.
Hallo,
ich habe grad Exchange 2013 CU12 auf CU23 gehoben, Server 2012 R2
.NET war 4.8 bereits im Updateverlauf. 4.5.2 unter installierte software.
lief ohne Probleme durch.
Hi, ja ich hatte auch schon mal solch ein Problem, bei mir gab es dabei keine Probleme. Jedoch war der Versionsunterschied nicht so hoch.
Hi zusammen,
ich habe einen Exchange 2013 Sp1 /Cu4 geerbet inkl .net 4.8.
Hat jemand schon direkt auf CU23 mit .net 4.8 geupt ?
ja, Antivirus Software vorher deinstalliert. Lief glatt durch, auf einem 2012R2.
Exchange 2013 CU 16 ist installiert und läuft (auf Server 2012 R2).
Exchange 2013 CU 23 versucht zu installieren. Abbruch mit Fehlermeldeung:
Fehler:
Der folgende Fehler wurde generiert, als „$error.Clear();
Install-ExchangeCertificate -services IIS -DomainController $RoleDomainController
if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
{
Install-AuthCertificate -DomainController $RoleDomainController
}
“ ausgeführt wurde: „System.Security.Cryptography.CryptographicException: Das Zertifikat ist abgelaufen.
bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
bei Microsoft.Exchange.Configuration.Tasks.Task.b__b()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.
Exchange läuft jetzt nicht mehr.
Hat jemand eine Lösung des Problems?
Na dann Glück gehabt, hatte ich aber auch schon ein paar mal. Da hat eine 3rd Party Patch Software bereits .Net 4.7.x installiert und der Exchange lief auch ohne Probleme weiter (bis auf das die OWA ab und an nicht startete, iisreset hat das jeweils behoben)
Da war das ganze dann auch recht einfach, CU2x drüber Feierabend^^
Ich habe jüngst einen Exchange Server 2013 „geerbt“, welcher zuvor von einem anderen Dienstleister betreut wurde..also zumindest hat dieser Dienstleister den Server irgendwann einmal aufgesetzt…installiert ist Exchange 2013 SP1 Build 15.0.847.32 vom Februar 2014!
Bin gewillt, den obigen Workaround auszuprobieren, aber ich fürchte mich erwartet eine Katastrophe :-)
Hallo Domik,
brauchst dich eigentlich nicht fürchten, bereits mehrfach erfolgreich angewandt.
Mach vorher ein Backup vom Exchange und vom DC (bzw. wenn vorhanden allen DC’s)
Dann kann ja nix schief gehen.
Vom DC weil evtl. ja das Schema angepasst wird (bin mir nicht so sicher ob unbedingt nötig, würds aber sicherheitshalber machen)
Okay, das macht mir Mut! :-)
Am morgigen Freitag Abend weiß ich mehr, werde dann mal Rückmeldung erstatten!
Kam am vergangen Freitag dazu, das Update zu installieren.
Zu meinem Erschrecken stellte ich hierbei fest, dass auf dem Server bereits das .Net Framework 4.7.1 installiert war…wie gesagt, Exchange 2013 SP1 ohne auch nur ein eigenes CU…
Gut, allen Mut beisammen genommen, Backup der VM mit Veeam erstellt, HyperV-Snapshot erzeugt, Cu23 drüber gebügelt…und nach einem Reboot funktionierte alles wie gehabt!
Hallo,
hat zufällig jemand Exchange 2013 CU17 irgendwo für mich als Download. Ich muss in unserer Testumgebung das Upgrade von CU17 nach CU22 durchführen und dokumentieren. Ohne das bekomme ich keine Freigabe den produktiven Server upzugraden. Leider habe ich keine Installationsmedien CU17 mehr. Die wurden von meinem Vorgänger „sicherheitshalber“ gelöscht.
Vielen Dank
Ralph
Hallo,
ich habe die Tage einen Exchange Server 2016 CU5 auf einem Windows Server 2016 übernommen.
Der Windows Server ist mit Stand Januar gepatcht.
Kann ich mit der oben genannten Anleitung diesen Exchange auf das aktuelle CU12 updaten oder ist noch irgendwas zu beachten?
Gruß
Bernhard
Soweit ich das verstanden habe kann man diese Variante eigentlich immer nutzen.
Habe es bisher auch auf einigen 2013 und 2016er eingesetzt und keine Probleme gehabt.
Da so ja der Exchange überhaupt nicht in Kontakt mit dem nicht unterstützten .net Framework kommt, da die Dienste ja aus sind.
Hatte auf unserem Exchange 2013 CU7 aus Versehen über den WSUS das .Net 4.7.1 freigegeben. Der Server hatte auch schon mit der installation begonnen und wollte den Neustart. Mit dem oben beschreibenen Weg hat das Upgrade von CU7 auf CU22 fast ohne größere Probleme funktioniert
Beim abschließen der Installation kam dann ein Fehler (Der folgende Fehler wurde generiert, als „$error.Clear();
$dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, „bin“……)
, und der Wartungsmodus konnte nicht mehr beendet werden. Alle Komponenten blieben auf „Inactive“.
Lösung: https://www.codetwo.com/admins-blog/exchange-2013-components-inactive/
Hallo Frank, zuerst einmal Danke für deine Webpage. Hat mir schon einige Male geholfen.
Ich bin ein Anfänger was Exchange betrifft.
Ich möchte von Exch 2013 CU17 auf CU21 aktualisieren,
da ich CU19 nirgendwo mehr downloaden kann muss ich direkt mit CU21 aktualisieren.
Aktuelles Szenario:
Einen Exchange Server / kein DAG / kleines AD / aber gleichzeitig zweiter DC.
Da ich nicht weiß ob die CU’s 18 – 20 irgendeine AD Schema Änderung beinhaltet haben und somit auch das CU21 dann beinhaltet (kumulativ, CU 21 ja nicht) folgende Frage.
Muss ich nur „setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms“ ausführen?
Die Exchange Dienste muß ich vor der eigentlichen Installation wirklich stoppen (Maintenance Mode)?
Habe nur bei Dir bisher den Hinweis darauf gefunden.
Deaktiviert nicht das Setup automatisch die Dienste?
Danke
Jürgen
Vielen Dank für die Lösung.
Upgrade Exchange 2016 CU7 -> CU21
bricht bei Schritt 10 mit Service Host Fehler ab.
Da hat mir folgender Blog Eintrag geholfen, und das Update lief durch.
https://blogs.technet.microsoft.com/karthikm/2016/09/28/unable-to-upgrade-cu-the-installation-source-for-this-product-is-not-available-verify-that-the-source-exists-and-that-you-can-access-it-error-code-is-1612/
Vielen Dank
Vielen Dank für die Lösung hier, hat mir bei einem ähnlichen Problem geholfen:
Upgrade Exchange 2016 CU7 -> CU9
bricht auch bei Schritt 10 mit Service Host Fehler ab.
Danach 2 Tage lang alles rumprobiert, weil ich nicht mehr in die EMC / OWA / ECP kam. Gottseidank hatten wir eine DAG.
Hab alle Verzeichnisse neu gemacht, Config Dateien getauscht, bis ich es geschafft habe eine CU7 Reparaturinstallation drüber zu jagen.
Was mir aber noch fehlte zum endgültigen Glück war eine Schleife, die automatisch die Exchange Dienste wieder auf Automatisch stellt, weil das Setup von CU7 als auch CU9 es nicht geschafft hat, das in der Installation von Deaktiviert zurückzustellen.
@Aberle: Wir hatten am Montag das selbe Problem. CU20 hat bei der Prüfung alles für OK befunden, AV-Programme/ Dienste (Trend Micro für Exchange) inaktiv. Dannach bei Punkt 1 der Abbruch des Setups. Nix ging mehr. Allse Dienste angehalten usw…. Musste auch den Exchange aus dem Veeam-Backup zurückzaubern. Aber da das Backup vom Vortag 23 Uhr war gab es auch Probleme mit dem DC und der Firwall, die keine Mails von Extern und Intern zustellen konnte. Da hat mir Frank wieder helfen können: https://www.frankysweb.de/exchange-2013-smtp-421-4-3-2-service-not-active/ . War ein echt schöner Feiertag für mich :-). Bin wieder auf CU19 und habe keine Lust nochmal das Ganze durchzumachen….
Hallo zusammen, kann ich CU’s trauen die ich über inofizielle Kanäle erhalten habe und von Microsoft signiert sind? Oder müsste man eher einen Case machen für CU15?
Hallo Florian,
warum aktualisiert du nicht, wie von MS empfohlen, direkt auf das aktuelle CU? Mittlerweile gibt es doch Klarheit wie das Update durchgeführt wird, es gibt also keinen Grund ein altes CU über inoffizielle Kanäle zu beziehen.
Gruß, Frank
Hey Leute,
erst mal danke für die Anleitung, hatte das problem das wir noch nen Exchnage 2013 mit CU5 hatten, wollte dann die Anleitung durchgehen und habe festgestellt, das wieso auch immer bereits .Net 4.7.1 auf dem Server installiert war, trotzdem funktionierte der Exchange?
habe dann mal Alle Dienste beendet und das Update auf CU20 durchgeführt, das ist beim ersten mal abgebrochen weil der Dienst Microsoft Exchange UM als „zum löschen“ markiert war, ahbe die markierung dann in der registry gelöscht, den Server neugesatrtet das Setup erneut angestoßen und die installation lief ohne Probleme durch.
Etwas seltsam aber hat geklappt.
trotzdem wäre es echt cool, wenn mir jemand das CU Bereitstellen könnte und evtl. noch die UM Language exe DE
wenns geht an: flodi88@outlook.de
Danke
Gruß Florian
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!
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?
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
@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.
Wenn ich das richtig in Erinnerung habe, ist das nicht entscheidend, in welcher Reihenfolge die Dienste gestoppt/gestartet werden.
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“?
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
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.
Danke für den Tip!
Ich habe bei jedem Schrittwechsel manuell mit Powershell schnell die Dienste auf Auto gesetzt xD
Also, ich mach grad den Sprung von CU9 auf CU23 – ich frage mich inwieweit das mit dem deaktivieren der Dienste überhaupt notwendig ist, da das Setup ja anscheinend selbständig die Dienste deaktiviert und wieder aktiviert.
Das manuelle deaktivieren ist da eher kontraproduktiv!
Entweder sollte man den Schritt komplett aus der Anleitung entfernen – oder nochmals ausdrücklich darauf hinweisen, dass die Dienste unmittelbar vor dem Setup wieder auf Auto gesetzt werden müssen!
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
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
@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.
Habe auf dem Exchange 2013 CU 15 .net 4.7.02053.
Kann ich dennoch direkt auf CU19?
Kann ich vor der Installation von CU19 auch das Update auf .net 4.7.1 machen?
Gemäss Matrix von Microsoft sollte das gehen https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx
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?
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
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“
Hallo Aberle,
den OneDrive Link musste ich entfernen.
https://www.microsoft.com/de-de/rechtliche-hinweise/urheberrecht.aspx#weitergabe-von-software
Gruß,
Frank
Hallo Patric,
vielen lieben Dank
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?
Hallo Patric,
ich bräuchte ebenso wie Gunther das Ex2013 CU15 sowie das UMLanguagePack.
Könntest du dies bereitstellen?
Gruß Sebastian
Hallo Patric,
ich bräuchte das cu 15 und umlanguagepack.
viele Grüße
Gunther
Hallo zusammen
Falls noch jemand auf der Suche nach „Exchange2013-x64-cu15.exe“ und „UMLanguagePack.de-DE.exe“ ist, könnte ich ebenfalls helfen ;-)
Der Beitrag ist ja schon älter aber gerne würde ich auf dieses Angebot zurück kommen wenn Du diese Exchange Version noch hast?
Gerne wird zusätzlich die CU19 oder CU20 auch noch genommen!
Das wäre super!
Hallo,
falls Du die Datein noch hast…
Ich könnte diese brauchen! ;-)
@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.
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?
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.
@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! ;-)
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.
Hallo Jann,
Dann stellt sich ja noch viel mehr die Frage danach woher die alten CUs nehmen wenn nicht stehlen…?
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
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?
Geht ein exchange 2013 „älter CU15“ denn „kaputt“ wenn man ihn erst Dotnet 4.7 und anschließend den cu19 verpasst…?