In an earlier article I have already pointed out that it is important to consider the NET dependencies of Exchange. In theory, all Exchange updates are cumulative, i.e. the current CU contains the complete installation files as well as all previous patches. The CU can therefore be used to perform a new installation or to update an existing installation. In theory, an Exchange 2013 RTM installation, for example, can also be updated directly to the current CU. However, this is only the case in theory, as there are dependencies on the NET Framework version used and supported.
Michel de Rooij has created a nice graphic for the dependencies of the NET Framework versions to the Exchange version, which clearly shows that intermediate steps are sometimes necessary when updating an old Exchange 2013 installation:
The problem is already clear in the graphic: An Exchange 2013 installation with CU4 cannot be updated directly to CU19 because CU4 does not support NET Framework 4.6.2. NET 4.6.2 is, however, a prerequisite for CU19.
The installation must therefore first be updated to CU15, then the NET Framework can be updated to NET 4.6.2 and only now can Exchange 2013 CU19 be installed. The next intermediate step is already waiting in the wings, as NET Framework 4.7.1 will be a prerequisite for future CUs (these dependencies also exist for Exchange 2016).
As far as the problem is concerned, the intermediate step via CU15 must currently be taken in order to bring an old Exchange 2013 installation up to date. The stumbling block lies in a completely different area:
Where to get the CU15?
Microsoft no longer offers the CU15 for Exchange 2013 directly as a download, the link to the old CU15 download leads nowhere and the update page only contains the note that there is already a newer update. There is already a sobering thread about this in Technet:
However, the answer is not very helpful at first: Contact Microsoft...
If you still have the CU15 somewhere on your hard disk, you should not delete it at the moment. You might need it again...
I took the liberty of sending a request to MS to find out if it is really necessary to contact support to get a download link to the CU15. As soon as I have an answer, I will update the article.
Update 02.01.2018
Here is the answer from MS Support to my request. I did not receive a download link for the CU15, but I did receive a workaround. However, the case is not yet closed and I will ask again in more detail and update the article here.
Update 04.01.2018
I tried the recommended workaround once. However, I only had an Exchange 2013 server without DAG to hand. I proceeded as follows:
- All Exchange services stopped and set to start type "Deactivated"
- NET Framework 4.6.2 installed
- Server restarted
- All Exchange services set to start type "Automatic", but finished serene
- CU19 installed
- Server restarted
The individual Exchange 2013 server has started cleanly and appears to be functioning normally. If you are running an Exchange 2013 DAG, you must first put the DAG into maintenance mode (Performing maintenance on DAG members)
Do not forget to set the Exchange services to start type "Automatic" again after the first restart, otherwise the installation of CU19 will fail:
Update 26.01.2018
The method described above is now also available as a note on TechNet:
Nevertheless, care should be taken to ensure that the Exchange servers are provided with the latest updates.
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…?