Beiträge

Veröffentlicht am

Windows7 Systemdisk voll durch CAB Dateien in temp Verzeichnis

Ich konnte schon mehrfach beobachten, dass sich auf relativ neuen Windows 7 Clients die Systempartition stark füllte. Oder besser gesagt, Veeam Endpoint informierte mich rechtzeitig darüber. 😉
Nach kurzer Untersuchung mit SequoiaView fand ich eine große Anzahl Dateien mit Namen CAB_xxxx im Verzeichnis C:\Windows\Temp. Diese waren etwa 50 MB groß und es gab hunderte davon.

Win7CABFill01Etwas Recherche legte offen, dass diese Dateien von der SFC.exe produziert werden, welche zur Windows Resource Protection gehört.

„Windows7 Systemdisk voll durch CAB Dateien in temp Verzeichnis“ weiterlesen

Veröffentlicht am

Veeam vPower NFS Datastore automatisch entfernen

Nach einem FLR (File level recovery) hinterlässt Veeam Backup einen vPower NFS Datastore auf dem ESX Host. Dieses Verhalten ist gewünscht, da es den Prozess beim nächsten FLR verkürzt. Hin und wieder führt jedoch der inaktive Datastore zu Problemen, oder man möchte einfach nur keine Relikte auf dem Host haben.
Niels Engelen von Virtual bits and bytes hat aus diesen Grund ein powerCLI Skript erzeugt, um diese NFS Datastores automatisch zu entfernen und dieses in seinem Blogbeitrag veröffentlicht.
Dieses Skript, das man einmalig oder als geplanten Task ausführen kann, entfernt alle Datenspeicher, deren Name mit VeeamBackup_ beginnen.

Veröffentlicht am

ESET ERA 6 Server Appliance manuell aktualisieren

Nicht immer läßt sich die ERA Appliance komfortabel über die WebGUI aktualisieren. Ein Fehler im Software Install Task verlangt dann doch den Griff zur Konsole.

Ablauf

  • Der erste Schritt sollte ein Snapshot auf der VM sein.
  • Download der Standalone Setup Dateien vom ESET Downloadserver
  • Verbindung mit SSH / SFTP Client zur ERA Appliance. Der User ist root und das Kennwort ist das identisch mit dem des Administrators der webGUI.
  • Installation von unzip, falls auf dem System noch nicht vorhanden
  • Ausführung der update Shellskripte

„ESET ERA 6 Server Appliance manuell aktualisieren“ weiterlesen

Veröffentlicht am

VM Template in Clustern mit heterogenen CPU Generationen

Probleme bei der Ableitung vom Template

Ich konnte in der Vergangenheit immer wieder beobachten, dass die Ableitung vom Template gelegentlich scheiterte und die neue VM in einem endlosen Sysprep fest hing. Eine erneute Ableitung führte oftmals zum Erfolg, aber die Hintergründe waren mir bislang unklar. Nur durch Zufall bin ich heute auf die Ursache des gestoßen. Die VM war für automatische Anmeldung als Administrator konfiguriert und ich konnte sehen was unmittelbar vor dem Sysprep Versuch passierte. Es wurde ein Treiber für die CPU installiert und der Anwender zu einem Neustart aufgefordert.

sysprepCPU03Dies ist erstaunlich, da das Template der VM zuvor intensiv mit Updates versorgt und mehrfach neu gestartet wurde. Warum also wird nach dem Ableiten ein neuer CPU Treiber installiert?

Dazu muss man verstehen, dass sich der der beschriebene Cluster aus zwei unterschiedlichen Typen von Intel Servern zusammensetzt.

  • Xeon E5-2640 – Dual Socket Hexa-Core
  • Xeon E5-2690 v3 – Dual Socket Dodeca-Core

Durch EVC wurde die vMotion Komaptibilität zwischen den Hosts sichergestellt, dennoch muss das Template jeden Host Typ einmal „sehen“, um den passenden CPU Treiber zu installieren. Passiert dies erstmalig nach dem ableiten, so ist der Sysprep Vorgang gestört und scheitert.

Prevention

Es zeigt sich, daß es eine gute Praxis ist, ein Template auf jedem Host Typ im Cluster mindestens einmal zu booten. Sind erst alle Treiber installiert gibt es auch keine Probleme mehr bei der Ableitung.