Kurze Information für Nutzer und Administratoren, die auf Veeam Backup & Replication setzen. Veeam hat zum 11. März 2026 Nutzern Sicherheitshinweise zu gravierenden Schwachstellen (CVSS v3.1 Score teilweise bei 9.9) zukommen lassen und auch Sicherheitsupdates bereitgestellt. Betroffen sind Veeam Backup & Replication 12 und 13. Auch vom BSI gibt es bereits eine Warnung.
Ich bin gestern von zwei Blog-Lesern per Mail über diese Sicherheitshinweise von Veeam informiert worden (danke für den Hinweis). Zudem gibt es vom BSI die Warnung [WID-SEC-2026-0709] Veeam Backup & Replication: Mehrere Schwachstellen.
Sicherheitshinweis zu Veeam Backup & Replication 12
Mit Datum 12. März 2026 wurde vom Hersteller der Sicherheitshinweis KB4830: Vulnerabilities Resolved in Veeam Backup & Replication 12.3.2.4465 veröffentlicht. Dort wird über eine Reihe von Schwachstellen in Veeam Backup & Replication 12.3.2.4165 und älteren Versionen informiert.
- CVE-2026-21666: Kritische Schwachstelle mit CVSS v3.1 Score: 9.9; Diese ermöglichtes einem authentifizierten Domänenbenutzer die Remote-Code-Ausführung (RCE) auf dem Backup-Server durchzuführen.
- CVE-2026-21667: Kritische Schwachstelle mit CVSS v3.1 Score: 9.9; Eine Sicherheitslücke, die es einem authentifizierten Domänenbenutzer ermöglicht, Remote-Code-Ausführung (RCE) auf dem Backup-Server durchzuführen.
- CVE-2026-21668: Als Hoch bewertete Schwachstelle mit CVSS v3.1 Score: 8.8; Ermöglicht es einem authentifizierten Domänenbenutzer Einschränkungen zu umgehen und beliebige Dateien in einem Backup-Repository zu manipulieren.
- CVE-2026-21672: Als Hoch bewertete Schwachstelle mit CVSS v3.1 Score: 8.8; Ermöglicht eine lokale Rechteausweitung auf Windows-basierten Veeam Backup & Replication-Servern.
- CVE-2026-21708: Kritische Schwachstelle mit CVSS v3.1 Score: 9.9; Ermöglicht es einem Backup Viewer , als Postgres-Benutzer Remote-Code-Ausführung (RCE) durchzuführen.
Laut Veeam wurden die obigen Schwachstellen mit Veeam Backup & Replication 12.3.2.4465 geschlossen.
Sicherheitshinweis zu Veeam Backup & Replication 13
Ebenfalls zum 12. März 2026 wurde der Veeam Sicherheitshinweis KB4831: Vulnerabilities Resolved in Veeam Backup & Replication 13.0.1.2067 veröffentlicht. Die beschriebenen Sicherheitslücken betreffen Veeam Backup & Replication 13.0.1.1071 und alle früheren Versionen der Build 13.
- CVE-2026-21669: Kritische Schwachstelle mit CVSS v3.1 Score: 9.9; Ermöglicht es einem authentifizierten Domänenbenutzer, Remote-Code-Ausführung (RCE) auf dem Backup-Server durchzuführen. Eine Windows-basierte Schwachstelle in Veeam-Sicherung und -Replikation, die bei internen Tests entdeckt wurde.
- CVE-2026-21670: Eine als Hoch bewertete Schwachstelle mit CVSS v3.1 Score: 7.7; Ermöglicht es einem Benutzer mit geringen Berechtigungen, gespeicherte SSH-Anmeldedaten zu extrahieren. Eine Windows-basierte Schwachstelle in Veeam-Sicherung und -Replikation, die bei internen Tests entdeckt wurde.
- CVE-2026-21671: Kritische Schwachstelle mit CVSS v3.1 Score: 9.1; Ermöglicht einem authentifizierten Benutzer mit der Rolle "Backup-Administrator" in Hochverfügbarkeitsumgebungen (HA) von Veeam Backup & Replication eine Remote-Code-Ausführung (RCE). Betrifft Veeam Software Appliance und wurde bei internen Tests entdeckt.
- CVE-2026-21672: Eine als Hoch bewertete Schwachstelle mit CVSS v3.1 Score: 8.8; Ermöglicht eine lokale Rechteausweitung auf Windows-basierten Veeam Backup & Replication-Servern.
- CVE-2026-21708: Kritische Schwachstelle mit CVSS v3.1 Score: 9.9; Ermöglicht einem Backup Viewer die Ausführung von Remote-Code (RCE) als Postgres-Benutzer. Betrifft das Windows-basierte Veeam Backup & Replication und Veeam Software Appliance.
Die Schwachstellen wurden in Veeam Backup & Replication 13.0.1.2067 geschlossen.
Fixes für Veeam Backup & Replication/Cloud Connect
Im Supportbeitrag KB3103: List of Security Fixes and Improvements in Veeam Backup & Replication gibt Veeam noch Fixes für Veeam Backup & Replication 10, 11, 12, 12.1, 12.2, 12.3, 12.3.1, 12.3.2 und 13, sowie für Veeam Cloud Connect 10, 11, 12, 12.2 und 12.3 bekannt. Dort werden die in den Produkten beseitigten Sicherheitslücken mit ihren CVE-Nummern aufgelistet.
Veeam Agent for Linux
Weiterhin hat der Hersteller die Sicherheitswarnung KB3109: List of Security Fixes and Improvements in Veeam Agent for Linux aus dem Jahr 2020 für Veeam Agent for Linux in den Versionen 4.0, 5.0, 6.0, 6.1, 6.2, 6.3, 6.3.1, 6.3.2 und 13 im März 2026 aktualisiert. Es wurden eine Reihe Open Source-Komponenten im Veeam Agent for Linux gefixt.
MVP: 2013 – 2016
Update auf die 12.3.2.4465 lief über die .EXE ist wie gewohnt problemlos und zügig.
Frage in die Runde: Wie sind die Erfahrungen mit der Version 13 bislang? Bei neuen Major-Versionen gibt es ja in der Regel erst mal einiges an Kinderkrankheiten, gerade wenn diese größere Veränderungen mitbringen.
Ich habe die V13 bei vier Installationen laufen. Das Upgrade war teilweise etwas aufwendiger, aber danach läuft das alles schon recht sauber. Die betroffenen Systeme mussten wir upgraden, damit wieder ein granulares Restore von zB Exchange Objekten möglich ist.
Die 13er-Windows läuft aalglatt. Haben wir über eine vorhandene 12er gebügelt.
Kritikpunt bei uns noch immer: Die Windows-Version updatet sich im Gegensatz zur Appliance nicht automatisch, was ich nicht nachvollziehen kann. Aber lt. Veeam-Support ist das wohl so gewünscht.
Ab Version 13 belegt Veeam den TCP-Port 443.
"Ja wer betreibt denn auch andere Anwendungen auf seinem Backup-Server???" Vielleicht kleine Einrichtungen, bei denen es überhaupt nur einen Server gibt.
Naja, da dann dennoch nicht zu virtualisieren und damit zu segmentieren ist doch Schmarrn, da kann die Einrichtung noch so klein sein. Sogar auf meinem Homeserver (HP Elitedesk USFF) läuft Proxmox.
Du unterschätzt, wie eng der finanzielle Spielraum bei kleinen Unternehmen ist. Da läuft dann oft nur eine Standard- oder sogar nur Essentials-Lizenz. "Nur für ein einzelnes Programm" eine neue Server-Lizenz + CALs erwerben und eine neue VM aufsetzen lassen – das macht kein kleiner Mittelständler mit drei oder vier PC-Arbeitsplätzen, schon gar nicht mit der Begründung "ist schöner so". Da ist man teilweise schon froh, wenn es überhaupt eine Domäne gibt.
Und selbst wir haben erst vor zwei Jahren im Rahmen einer größeren Austausch- und Erneuerungsaktion VEEAM auf eine separate VM ausgelagert. Letztlich muss ich mir immer die Frage stellen: Wie viel Nutzen erhalte ich für die Investition? Kann ich mit dem Geld eventuell auch andere Dinge machen, die mir mehr Nutzen (in der IT) bringen?
@alle anderen: Danke für die Rückmeldungen und Erfahrungsberichte!
Haufenweise Probleme mit 13 Anfangs, von einer abgeschossenen VM die auch gleich noch den ganzen Cluster beeinträchtigt hat, wie auch immer das ging. Der Umstieg auf enforced OpenSSL FIPS harmoniert scheinbar nicht mit anderen Anwendungen, die auch ihr eigenes OpenSSL mitbringen, guest processing schlägt random fehl ohne auszureichende Begründung, woran es scheitert. Ich wäre lieber bei 12.3 geblieben hätten sie den Support für weitere OS ausgeweitet, somit war ich zum Upgrade gezwungen.
Die Installation wird immer mehr zugemüllt, es starten etliche Services automatisch mit, die kein Mensch braucht, statt dass man modular arbeitet und nur die Services startet für die Plugins, die man wirklich nutzt und braucht.
Bin nicht ganz so zufrieden wie das Upgrade abgelaufen ist, aber zumindest läuft es langsam wieder rund.
>>Die Installation wird immer mehr zugemüllt, es starten etliche Services automatisch mit, die kein Mensch braucht, statt dass man modular arbeitet und nur die Services startet für die Plugins, die man wirklich nutzt und braucht. <<
Full ack!
Wir können seit der 13er aktuell nicht mehr per VSS sichern. Die Backup Server befinden sich in einem isolierten Verwaltungsnetz und haben keine direkte Netzwerkverbindung zu den VMs. Wenn ich das richtig verstehe wird die VSS Sicherung dann mittels Powershell durchgeführt, was aber -warum auch immer- regelmäßig nicht klappt, entweder sehr lange dauert oder komplett eskaliert.
Beschrieben wird das hier:
https://forums.veeam.com/microsoft-hyper-v-f25/guest-interaction-failing-after-veeam-13-upgrade-t101402.html
Nach einem Neustart des Hyper-V Hosts funktioniert es interessanterweise manchmal für einige Tage oder auch Wochen dann doch wieder, aber nie dauerhaft.
Das Update hat wohl auch das VSS Problem behoben. Meine Testläufe haben zumindest alle funktioniert und ich werde es jetzt für alle VMs reaktivieren und schauen ob es nachts durchläuft.
Hallo in die Runde,
wir hatten das Problem beim Upgrade auf die 13er Version, dass der Login an der Konsole danach nicht richtig funktionierte. Wenn es dann mal geklappt hat, konnte man aber kein Application Restore (SQL /Exchange Items) durchführen. Es kam sinngemäß immer eine timeout Meldung und dies sowohl bei den Anmeldeversuchen als auch beim Restore.
Letztendlich lag es an einer Zeitüberschreitung, da der Server während der Zertifikatsüberprüfung keine Verbindung zu ctldl.windowsupdate.com herstellen konnte. Aufgrund dieses Problems verbringt der Server mehr Zeit mit Wiederholungsversuchen, was zu der Zeitüberschreitung führt. Die Lösung war, im Local Group Policy Editor unter Computerconfiguration\Windows Settings\Security Settings\Public Key Policies den Object Type Certificate Path Validation Settings Reiter Network Retrieval die Option "Define these policy settings" aktivieren und dann die Option darunter "Automatically update certificates in the Microsoft…" zu deaktivieren.
vielleicht hilft es ja jemanden :-)
schönes Wochenende….
Gruß
Olli
Autsch! Wärs nicht einfacher, dem Server einen Zugriff auf ctldl.windowsupdate.com zu ermöglichen? Vor allem sicherer…
Ein Backupserver mit Internetverbindung? Halte ich für keine gute Idee. :)
Der Veeam Agent for Microsoft Windows FREE (https://www.veeam.com/de/products/free/microsoft-windows.html) ist auch betroffen, oder?
Gute Frage … es kam zwar ein Update aber oben im Text steht davon nichts?
Kann ich nichts zu sagen, Veeam hat zu Veeam Agent for Microsoft Windows FREE keinen Sicherheitshinweis veröffentlicht (jedenfalls habe ich nichts gefunden). Da das Produkt aber auf den oben erwähnten Veeam-Produkten aufsetzt, dürfte es auch gefährdet sein. Beantworten kann das aber nur der Hersteller.
Ok vielen Dank
habs bei uns jetzt trotzdem ausgerollt… sind nicht viele Rechner die betroffen waren aber war jetzt ne schöne Freitags-Arbeit ;-)
Aber keine CVE und auch kein Hinweis, da sind die agents wohl nicht von den Lücken betroffen ( Ersetzt, das Patchen aber nicht)
Technisch ist der Agent ja kein eigenständiges Produkt, sondern Bestandteil von VEEAM B&R, der halt nur (das ist aber eher eine kaufmännische Entscheidung) in einem freien Modus betrieben werden kann.
Ob er wirklich betroffen ist werden wir erst erfahren, wenn wir wissen, welche Komponente der Auslöser war. Meine Vermutung: OpenSSL
Wenn man sich an die best practices hält, dann ist das fast vollständig irrelevant: Was hat ein Backup-Server mit der Domäne zu tun? Gar nichts! Patchen werden wir natürlich trotzdem, daher danke für den Hinweis.
Hi,
Da sind aber auch CVEs die nichts mit einem auth. Domänen Benutzer zu tun haben? Also wie du bereits erähnt hast, Patchen werden wir natürlich trotzdem ;)
Ich verstehe es so, dass ein Backup Viewer in Domäne A z.B. u.a. Adminrechte auf Datenbanken erhält, die in Domäne B und C sowie ohne Domäne genutzt werden. Mitarbeiter von Veeam sind damit dann z.B. Datenbank-Admin bei allen Kunden. Dabei ist es egal, ob der Backup-Server physikalisch (optimal), virtuell oder gar nicht (nicht empfohlen) vom zu sichernden System getrennt ist.
Wobei das nicht in allen Szenarien vermieden werden kann, den Backupserver in die Domäne aufzunehmen. Die neue Appliance muss in Kombination mit gewissen Funktionen in Hyper-V Clustern Mitglied der Domäne sein, sonst funktioniert nicht alles. Da die Appliance aber auf Linux läuft und gehärtet ist sieht Veeam hier aber kein Problem, da der Angriffsvektor der bei einem Windows VBR in der Domäne existiert dort nicht gegeben ist.
Eine andere Frage könnte sein, warum muss die Gruppe "Domain Users" in der lokalen Gruppe der "Users" auf einem Backup Server sein? Alternativ könnte man (zusätzlich) im Rahmen eines Tierings zusehen, dass die * Logon Rights ausschließlich berechtigte Konten ans System lassen. :-)
Gutes Thema… eicht es immer noch nicht, dass ein Veeam-Service-Account einfasch nur Mitglied in der "Backup-Operators" Gruppe ist, oder muss er immer noch lokale Adminrechte haben, um einen Server sichern zu können?
Ich habe die Doku kurz überflogen und fürs Guest Processing wird dort fast immer Mitglied der lokalen Administratoren gefordert.
Gegen Ende des Tages kommt man dann halt zu der Frage, ob man für seine Tier0, Tier1 (, Tier2) Assets jeweils eine eigene Veeam-Instanz hat, genau wie man dann auch eine eigene Monitoring-, Patching- oder auch Virtualisierungsinstanz haben sollte.
Wichtig ist aus meiner Sicht, dass die Server, Clients und User keinerlei Zugriffsrechte auf irgendeinen Teil der Veeam Backup Struktur haben. Diese habe eine rein passive Rolle beim Backup und können sich auch an keiner Konsole oder Verwaltungsstruktur anmelden.
Alle Backups werden durch den Veeam B&R Server im Pull-Verfahren erstellt. Der Server hält die Zugangsdaten zu den zusichernden Systemen im Identity-Store von Veeam. Das können z.B. Zugangsdaten für ein Virtual Center von VMware sein (welches besser auch nicht an der Domäne hängt!) oder diverse Service User, welche sich gegenüber den Servern einer Tier authentifizieren können. Veeam unterstützt auch den Einsatz von gMSA (Group Managed Service Accounts), es gibt aber einige Einschränkungen und Voraussetzungen zu beachten.
Nach dem Backup kann man die Daten fast beliebig auf sekundäre Ziele verteilen. Wir schieben z.B. Kopien zusätzlich in ein Veeam Hardened Linux Repository und auf die guten alten LTO-Bänder. Den Ansatz alle Tiers mit eigenen Backup-Server zu sichern und so weiter zu separieren finde ich gut. Das wird aber am Ende auch eine Frage der Kosten sein. Besser geht quasi immer, am Ende muss das aber auch alles einer warten, patchen, managen und bezahlen.
So, das Update wurde die über die ISO installiert. 12.3.2.4165 -> 12.3.2.4465
Es hat alles ohne Probleme funktioniert. Die Remote Komponenten auf anderen Servern im Veeam Verbund wurden automatisch hochgezogen, die Agents auf einzelnen Clients mit Backup habe ich manuell durchgetreten (Rescan + Update).
Habe mit der Exe von 13.0.1.1071 auf 13.0.1.2067 geupdatet.
Keine Probleme.
Jedes Jahr eine neue schwere Lücke in Veeam B&R.
Sol langsam kommt es mir so vor als wenn hier eine gewisse Absicht vorliegt, die Kunden immer wieder zum Kauf der neusten Version zu bewegen.
Wie wenig Aufschrei es gibt, wenn mal wieder eine ganze Reihe schwerer Lücken in Veeam öffentlich werden. Microsoft wird dafür jedes Mal in der Luft zerrissen.
Ich halte mich ja oft bewusst als Betreiber mit Kommentaren zurück. Zwischen Veeam und Microsoft sehe ich bezüglich Aufschrei doch a bisserl Unterschiede. Wenn dieses Microsoft meint, die Nutzer mit allerlei Gimmicks drangsalieren und zwangsbeglücken zu müssen, dann durch den Krempel voraussehbar gravierende Sicherheitslücken reißt, und dann ggf. auch noch mehrere Schüsse zur Korrektur braucht, ist das schon eine andere Nummer als Sicherheitslücken bei Veeam. Da ist es nachvollziehbar, dass "in der Luft zerrissen wird". Fehler können immer passieren, und Sicherheitslücken werden bekannt – das werden die meisten Leute tolerieren. Es ist dieses "wir wissen, was für dich als Kunde gut ist", von Microsoft, was zumindest bei mir einen gewissen Reflex beim Bloggen auslöst. Ich vermute, es geht anderen ähnlich.
PS: Praktisch bin ich dagegen arg entspannt (Linux und Win 10 2019 Enterprise LTSC lässt mich ohne das neue Geraffel wie Copilot arbeiten, MS365 und die Cloud verwende ich nicht).
"mit allerlei Gimmicks" drangsalieren passt allerdings auch durchaus für Veeam B&R. Das Produkt ist mittlerweile derart aufgebläht mit Funktionen, die wahrscheinlich 90% der Instanzen überhaupt nicht benötigen. Dass man sein Produkt um Funktionen erweitert ist ja ok, aber dass das alles standardmäßig mit ausgerollt wird, das kann man imo begründet kritisieren, zumal das unter dem Aspekt der Sicherheit auch ganz sicher kein best practice darstellt.
Da muss ich mich bedeckt halten, da ich Veeam nicht verwende.
Technisch ist VEEAM B&R schön modular aufgebaut.
Was halt nervt ist die Tatsache, daß trotzdem vom Installer immer alle Module und Integrationen mit auf die Platte gekübelt und gestartet werden, auch wenn man nie vorhat, ein Nutanix, einen S3 oder eine Google Cloud anzubinden.
Deinstalliert man einzelne Module gibt es spätestens beim nächste Update Mecker wegen einer defekten Installation.
Das beschreibt das Problem. Was hilft mir der modulare Aufbau, wenn ich eh immer alles untergeschoben bekommen. Jedes einzelne Modul ist zudem eine potenzielle Sicherheitslücke.
Habe ich auch nicht verstanden. Dazu ein 20 GB-Image für eine Backupsoftware.
Kann ich nur beipflichten.
Ja, Veeam ist mächtig. Aber muss es deswegen gefühlte Minuten zum Starten der GUI brauchen? Oder zum Schließen mehrere Sekunden? Er muss ja nicht mal irgendwas in die Datenbank zurückschreiben. Und da sprechen wir noch nicht von Bedienung über Proxies an anderen Standorten. Das ist schlicht unmöglich (5min+ für Öffnen).
Gefühlt wurde es auch nochmal deutlich schlechter mit PostgreSql gegenüber SQL Express (wie schafft man das?!).
Ich hoffe 13 ändert daran was, aber ich bezweifle es…
Interessanterweise habe ich dieses Mal von VEEAM keine Mail bekommen.
Auch nicht im SPAM. Erst hier gelesen und gleich aktualisiert.
Solange ich von Lesern informiert werde, und es persönlich gebacken bekomme, plane ich weiterhin Sicherheitshinweise von Veeam oder anderen Anbietern hier einzustellen (ist ja Sinn des Blogs). Es ist die Erfahrung der letzten Jahre, dass immer einige Leute keine E-Mail-Benachrichtigungen der Hersteller bekommen haben.
Hier genau das selbe, und wir sind Veeam Partner! Ist auch schon das zweite oder dritte Mal.
Das ist interessant. Aber wenn ich das richtig sehe, ist die Mail, die ich am 12.03.2026 um 14:03 Uhr bekommen habe, in der Tat ein manuell abonnierter Newsletter für "Veeam Security Advisory Updates", keine "extra" Rundmail an Bestandskunden.
Am Rande, das BSI meldet so ziemlich alle CVEs…
https://wid.cert-bund.de/portal/wid/kurzinformationen
ich musste den inhalt der Iso "VeeamBackup&Replication_13.0.1.2067_20260310_patch" auf die Platte kopieren und mit einem
Get-ChildItem -Path "C:\install\veeam" -Recurse | Unblock-File
den "Internet" Tag von den Dateien wegnehmen vorher war kein update möglich.
Und zu den "Beschwerden" über veeam – ich nutze das fast von Anfang an (2007 oder 2008) und wenn ich eine Info/mail vom Veeamrechenknecht bekommen hab, das Rechner x erfolgreich gesichert wurde, dann konnte ich bisher immer von dieser "angeblich" erfolgreichen Sicherung auch ein restore machen. Das konnte man bei Backupexec Arcserve usw. nicht immer behaupten.
Von daher, aber die"jemehrdestohastenichtgesehen" Ansatz nervt mich trotzdem auch.
Teufel, Belzebub Freitag, der 13 euer Robinson Crusoe ;-)
Das hat nichts mit VEEAM zu tun. Dateien aus dem Internet werden mit einem entsprechenden Attribut versehen und Windows warnt bei Benutzung.
Entweder "Unblock-File" oder, falls man eher maus-affin ist, die Eigenschaften der Datei anzeigen lassen und das passende Häkchen setzen.
Hi Fritz,
denk mal kurz drüber nach, warum jemand das geschrieben hat und was sich hinter " -Recurse " verbergen könnte.
Die Eigenschaften der Datei anzeigen lassen und das passende Häkchen setzen. Jede .ddl jede .exe?
Und das war bei mir der Fall, ich hab das für Leute geschrieben bei denen das gleiche genauso ist.
Tatsächlich hatte ich nur die .exe heruntergeladen, entblockt und gestartet – eine Datei.
Wenn alle Dateien auf der .iso dieses Attribut tragen hat vermutlich jemand beim Erstellen geschlampt, bei den bisherigen Vollinstallationen vom .iso habe ich das so noch nicht gesehen.
Um nochmal nachzuhaken:
Es handelte sich um eine ISO, die diesen Haken nicht hatte, die Dateien im ISO jedoch schon? Ein Fehler der bei Veröffentlichung durch Veeam passiert ist?
Bei anderen Archiven ist mir das als normales Verhalten bekannt. Falls ein Zip das "MotW"-Flag hat, wird das auf extrahierte Inhalte vererbt. Aber bei ISOs wäre das krass.
"Arcserve", dass man das Wort nochmal in einem aktuellen Text lesen kann! Da werden Erinnerungen wach!
Ein kleiner Hinweis: Wenn man die heruntergeladene ISO mit 7zip oder ähnl. auspackt, befindet sich dort ein Ordner "Update". Das Update dann mit der dort liegenden Patchdatei installieren, (man muss nicht das Setup benutzen, wo es möglicherweise erst das ganze "Geraffel" durchgeht).
Das Setup bietet das Update gar nicht an, sondern nur die Option für "Modify". War bei mir jedenfalls bei drei Instanzen so.
In der ausgepackten ISO gibt es einen Ordner "Updates", in der sich die Datei "VeeamBackup&Replication_13.0.1.2067_patch_20260310.exe" befindet. Diese Datei ist um die 2,8GB groß, (im Gegensatz zur gesamten ISO, die 19.6GB groß ist). Das Update mit dieser Datei hat bei mir auf 3 Systemen problemlos funktioniert.
Günter hat oben die VEEAM KBs für 12 (kb4696) und 13 (kb4738) genannt.
Bei beiden ist neben der vollen ISO (die man vielleicht zu Archivierungszwecken haben möchte) noch eine Patch-ISO (3.31 GB) und auch die Patch-EXE (2.79 GB) verlinkt. Die reichen für ein Update aus.
Ein 2 GB Patch? Was läuft da denn schief?
Vielen Dank für die Info. Bei mir wurde bei der "normalen" Installation auch, wie weiter unten bei einem anderen User, Modify angezeigt und die Lizenz wurde nicht erkannt. So lief die Installation problemlos durch.
Richtig. Man muss den Patch nehmen. Direkt aus der gemounteten Iso mit Rechtsklick (Admin) starten.
Ich habe heute auch den Windows Agent (Free) und Veeam B&R CE aktualisiert/gepatcht. Lief im Prinzip smooth.
Was nun aber passiert ist, dass nach dem einloggen in die Veeam B&R Konsole auf dem Desktop eine Ordnerstruktur wie folgt angelegt wird:
C:\Users\Administrator\Desktop\Veeam\Backup\AdvertisingControl_Elevated\EBWebView
Darunter zig weitere Ordner und Dateien. Insgesamt ist der so ~30MB groß (wächst evtl. auch). Kann den nach dem Schließend der Konsole löschen, aber er wird bei erneuten einloggen in die Konsole wieder angelegt.
Kann wer was dazu sagen?
Hmmm – sehr aufwendig bei mir
Hatte die Version 13 am laufen – das Setup zeigte mit auch Modify an. Danach kam aber "Another Version is running on this System"
Musste alles deinstallieren und neu installieren – Veeam Backup & Recover – Neue Sql Datenbank unter einem anderen Namen usw.
Dann hast du vermutlich die falsche Datei benutzt, nämlich das ISO für Neuinstallationen bzw. für Upgrades von älteren Versionen.
Für Systeme, die schon eine Version 13.0.1 haben, gibt es eine separate Patch-ISO bzw. eine Patch-exe. Da muss man dann auch nichts deinstallieren oder neu installieren, einfach nur den Patch drüber laufen lassen. Steht auch so im verlinkten KB Artikel.
"Spannend" war für mich, daß auf der Supportseite extra erwähnt wurde, daß man unbedingt zuerst (gegebenenfalls) den EnterpriseManager patchen soll und dann erst B&R.
Nachdem ich nirgends eine eigene Patchdatei für den EnterpriseManager finden hab können und die B&R-Patchdatei mir keine Option gab die Reihenfolge einzuhalten, war ich mutig und hab einfach den Patch durchgeklickt => (Auch der EnterpriseManager)Funktioniert sogar nach Reboots alles noch einwandfrei.