Backup-Exec 2012 Fehler LU1825

Live Update von Backup-Exec 2012 scheitert mit Fehler LU1825.

Im Live-Update Fenster wird ein Servicepack oder Hotfix für das installierte Produkt angezeigt. Nach dem Download bricht Live-Update mit der Fehlermeldung LU1825 ab.

LU1825: Dieses Update hat versucht, eine zu seiner Installation erforderliche Anwendung auszuführen. Die Ausführung der Anwendung ist jedoch fehlgeschlagen. Das Update ist dadurch möglicherweise beschädigt. Versuchen Sie, dieses Update bei der nächsten Ausführung von LiveUpdate abzurufen. Klicken Sie hier, um weitere Informationen zu diesem Fehler zu erhalten „Backup-Exec 2012 Fehler LU1825“ weiterlesen

DRS Cluster im Ungleichgewicht

Versetzt man einen ESXi Host im DRS Cluster in den Wartungsmodus, so wird die Last (VMs) auf die verbleibenden Hosts verteilt. Wird der Wartungsmodus beendet, kann man häufig beobachten, daß der jetzt frei ESXi Host nicht mit VMs befüllt wird. Auch nach Stunden, oder gar Tagen ist die Last immer noch stark ungleich verteilt. Ich habe mich schon oft gefragt, ob das DRS vielleicht falsch konfiguriert, oder gar defekt ist.

Es ist alles in Ordnung

Die Aufgabe von DRS besteht nicht darin, alle Hosts gleichmäßig auszulasten, sondern VMs die Ressourcen zu bieten, die sie benötigen. Das bedeutet: Wenn ein einziger Host genügend Ressourcen bereit stellt, um die Bedürfnisse aller VMs im Cluster zu bedienen, so besteht kein Grund VMs auf andere Hosts zu verschieben. Denn jede vMotion-Aktion kostet Ressourcen. Steht am Ende der Verschiebung kein Gewinn für die VMs, so ist dies als Verschwendung zu betrachten. Frank Denneman, der als Spezialist in DRS Fragen gilt, erklärt in seinem Artikel „Disabling MinGoodness and CostBenefit“ dieses Phänomen und warum man die Parameter MinGoodness und CostBenefit besser nicht manipulieren sollte.

MinGoodness und CostBenefit

Ein VMware KB Artikel erklärt, wie man die obigen Parameter außer Betrieb setzen kann. Doch was ist deren Aufgabe?

CostBenefit

vCenter überwacht das Verhalten aller VMs. Es berechnet, wieviele Ressourcen notwendig sind eine VM von HostA nach HostB zu verschieben. Je nach Last dieser VM können hierfür erhebliche CPU Ressourcen während des Verschiebevorgangs von Nöten sein. Das ist der „Cost“ Anteil in CostBenefit. Dem gegenüber steht der Nutzen durch frei werdenden Ressourcen auf dem Quell-Host nach der Verschiebung.

MinGoodness

vCenter wird normalerweise nur VMs auf Hosts verschieben, wenn diese eine geringere mittlere Auslastung haben als der urprüngliche Host. MinGoodness gibt DRS Auskunft, inwieweit die Verschiebung sich auf die Auslastung des Clusters auswirkt.

Setzt man beide Parameter in den erweiterten Eigenschaften des DSR Clusters auf Null, so vermittelt man dem DRS Algorithmus, vMotion Aktionen seien „kostenfrei“ und nach dem Umzug muss der Nutzen für Host und VM nicht signifikant höher sein als zuvor.

vCenter neu starten?

Ein billiger Trick, um vCenter zum Ausgleich des Clusters zu bewegen, war bisher der Neustart von vCenter. Der Grund, warum DRS danach bereitwilliger vMotion Aktionen auslöst ist recht einfach erklärt. Durch den Neustart „vergisst“ vCenter wie teuer ein vMotion einer bestimmten VM sein könnte, da historische Daten früherer Migrationen dieser VM verloren gehen. Man kann sagen, vCenter lässt sich nur aus Unwissenheit auf eine teure Verschiebung ein.

VMs mit ROK Key installieren

ROK Grundlagen

Microsoft Betriebsysteme können von Serverherstellern als sogenanntes Reseller Option Kit (ROK) bezogen werden. Dabei handelt es sich um speziell auf die jeweilige Hardware angepasste Versionen des entsprechenden Beriebsystems. Faktisch entspricht diese Version der Microsft System Builder Version, ist aber preislich deutlich günstiger und kann getrennt von der Hardware eingekauft werden. In der Regel sind diese Versionen mit einem BIOS Lock ausgestattet, so daß man sie nur auf der Original Hersteller Hardware installieren kann. D.h. ein Windows Server 2008R2 ROK von IBM kann auch nur auf IBM Hardware installiert werden. Das gleiche gilt für Fujitsu, HP, Dell etc. ROK Versionen werden als eigenständige Produkte vom Kunden erworben und von diesem auch selbst installiert. Der mitgelieferte Key muß auf der Hardware durch den Kunden angebracht werden. Nur dann gilt das System als korrekt lizenziert. Ein verlorener Key kann nicht bei Microsoft angefragt werden, da er dort nicht hinterlegt ist.

ROK und virtuelle Systeme

Soweit alles ganz einfach. Interessant wird die Sache aber wenn ROK Versionen in virtuellen Umgebungen eingesetzt werden sollen. Beispielsweise soll eine Windows Server 2008 R2 Datacenter Edition (Fujitsu ROK) in einer VM installiert werden, die auf einem Fujitsu ESXi Server läuft. Rechtlich ist das in Ordnung, wenn für jeden Knoten im Cluster eine Datacenter Lizenz vorhanden ist (notwendig für vMotion).

„VMs mit ROK Key installieren“ weiterlesen

Windows 7: Sysprep counter reset

Sysprep ist eine sehr nützliche Funktion wenn man VMs vom Template ableitet. Die neue VM wird durch den Sysprep Vorgang wieder in eine Art Urzustand zurückversetzt. So z.B. der Computername, die Domäne, das Profil des lokalen Administrator, sowie die SID.

Zu Problemen kann es kommen wenn man die abgeleitete VM wiederum zum Template verwandelt und davon erneut VMs ableitet. Denn es gibt einen Sysprep Counter, der diesen Vorgang dreimal zulässt. Spätestens nach der dritten Template Generation könnte folgende Fehlermeldung auftreten:

Date Time, Error [0x0f0073] SYSPRP RunExternalDlls:Not running DLLs; either the machine is in an invalid state or we couldn’t update the recorded state, dwRet = 31

Date TimeFehler [0x0f0073] SYSPRP RunExternalDlls:Not ausführen DLLs; entweder der Computer befindet sich in einem ungültigen Zustand oder konnte nicht aktualisieren wir den aufgezeichneten Zustand DwRet = 31

Um dies zu vermeiden muss man sicher stellen, daß der sysprep counter nicht nach jeder Ableitung hochgezählt wird. Dies ist entweder mit der SkipRearm Option von Sysprep möglich, oder man präpariert die VM, welche Template werden soll.

Template vorbereiten

Man bereitet ein Batchfile mit folgendem Inhalt vor und legt es im root von Laufwerk C ab.

reg load HKLM\MY_SYSTEM “%~dp0Windows\System32\config\system”
reg delete HKLM\MY_SYSTEM\WPA /f
reg unload HKLM\MY_SYSTEM

Anschliessend bootet man die VM in Windows Recovery environment (WinRE), indem man beim Reboot F8 drückt. Im Startbildschirm wählt man „Computer reparieren“. Anschliessend wählt man das Tastatur Layout.

Nach Eingabe von User und Passwort gelangt man ins Hauptmenü und wählt dort „Eingabeaufforderung“.

Dort startet man auf der Commandozeile das zuvor abgelgete Batchfile. Anschliessend wird die VM neu gestartet. Sie ist nun ohne Schlüssel und bereit für Sysprep. Die Warnung, daß dieses System nicht echt sei kann man zunächst ignorieren. In der Ableitungskonfiguration wird dieser VM wieder ein gültiger Schlüssel zugeordnet.

Links

Microsoft TechNet – Funktionsweise von Sysprep

Microsoft TechNet – SkipRearm

My Digital Life – How to Reset Available Remaining Rearm Count in Windows 7