Im Artikel “Don’t Panik – was tun wenn die vmdk Datei weg ist” habe ich beschrieben, wie man eine VMDK Header Datei auf Basis der letzten Logs rekonstruieren kann.

Jetzt wurde im NetApp Forum ein Tool bereitgestellt mit dem man dies automatisiert durchführen kann. Darüber hinaus ist es möglich bestehende Header Dateien zu überprüfen. Zu finden ist das Skript unter http://communities.netapp.com/docs/DOC-2735.

Gefunden habe ich den Verweis im Blog-Post http://www.yellow-bricks.com/2009/04/03/repairing-your-vmdk-header-files/.

Ich habe mich jetzt mal bei Twitter angemeldet. (@AllDoneHere)
Skeptisch bin ich immer noch, aber probieren geht über studieren. Natürlich hat dieses WordPress jetzt auch entsprechende Plugins zur Integration mit Twitter. Darunter fällt u.a. der Link “Send To Twitter” über jeden Post.

Gestern hat VMWare neue Updates für den ESX 3.5 und ESXi 3.5 Server herausgebracht.

Detailierte Beschreibungen zu den Änderungen sind unter folgenden Links zu finden:

ESX 3.5: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007971

ESXi 3.5: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007990

Ich hoffe ab morgen wieder Zugang zu einer Testumgebung zu bekommen, damit ich solche Neuigkeiten auch genauer testen kann…

Zeitweise stieg die Datenbankgröße des OpsMgr extrem schnell an. Um herauszufinden, woher dieses ungewöhnliche Verhalten kam, wollte ich ein Liste aller Alerts mit deren Summe des Auftretens erstellen. Früher wäre ich dafür direkt in die Datenbank gegangen. Heute gibt es dafür Powershell. Das ist einfacher und supported.

Die Liste lässt sich mit folgendem Einzeiler erstellen:

get-alert | group-object -property Name | sort-object count<br />
Der Aufbau ist recht einfach: Zuerst alle Alerts ausgeben (inklusiv der bereits geschlossenen). Diese Liste gruppieren nach der Eigenschaft Name. Als letztes die Ausgabe nach der Anzahl des Auftretens sortieren.

Im Rahmen einer Supportanfrage bei MS wurde ich auf eine einfache Möglichkeit hingewiesen, wie man aufzeichnen kann, wann welches Skript durch den OpsMgr Agent ausgeführt wird:

http://blogs.technet.com/jeevanbisht/archive/2008/12/09/OpsMgr-2007-How-to-identify-what-script-is-running-on-the-agents-_2F00_-frequency-_2F00_-parameters.aspx

Zusammenfassend werden die Filter im Process Monitor von Sysinternals (jetzt Microsoft) so gesetzt, dass der Start und das Ende von cscript.exe Prozessen aufgezeichnet werden. Da dabei auch die Parameter mit protokolliert werden, ist so einfach zu sehen ob und wann ein Skript mit welchen Eigenschaften aufgerufen wurde. Beim Prozessende erkennt man auch eventuelle fehlerhafte Exitcodes.

Während einer OS Installation über SCCM (MDT) ist die Installation der aktuellen HP Treiber durch das passende Support Pack sehr einfach möglich. Firmware Updates fand ich bis jetzt schon schwieriger.

Eine sehr einfache Möglichkeit ermöglicht die Firmware Update CD:
Die CD (ISO File) einfach entpacken (z.B. mit 7Zip) und als Paket im SCCM einbinden. Im Root des Paketes eine Batch Datei mit folgendem Inhalt anlegen:

"%~dp0FW840.2009_0209.17compaqswpackageshpsum.exe" /s /romonly /use_location "%~dp0FW840.2009_0209.17compaqswpackages"

Kurzer, schneller Post:

Heute habe ich ein mir unbekanntest Kommandozeilen Tool gefunden:

forfiles:

FORFILES [/P Pfadname] [/M Suchmaske] [/S]
[/C Befehl] [/D [+ | -] {dd.MM.yyyy | TT}]

Beschreibung:
Wählt eine Datei (oder einen Satz von Dateien) und führt einen
Befehl auf dieser Datei aus. Dies ist für Batchaufträge hilfreich.

Parameterliste:
/P    Pfadname      Bestimmt den Pfad, auf dem die Suche gestartet
wird. Standardordner ist der zurzeit
verwendete Ordner (.).

/M    Suchmaske     Sucht nach Dateien laut einer Suchmaske.
Die Standardsuchmaske ist “*”.

Gestern war es mal wieder so weit: Durch Storage VMotion wollte ich alte SAN Disks leeren. Daei blieb auf einer SAN-Disk Dateien einer VM zurück, die eindeutig schon verschoben war. In der Annahme, dass es sich dabei um Altlasten handelte, löschte ich diese spontan. Leider handelte es sich dabei um einen Clone der anderen Machine, die im Dateisystem leider den gleichen Namen behalten hat.

Die meisten Dateien waren gesperrt und konnten zum Glück nicht gelöscht werden. Was aber erst später auffiel: Es wurde erfolgreich die Description Datei der Platten gelöscht:

Treibermanagement in SCCM ist recht einfach gestaltet, trotzdem sollte man eine gewisse Organisation und Vorsicht walten lassen. Daher mal diesmal ein paar Basics:

Eindeutiges Zeichen für einen Fehler ist folgender Bluescreen (0xc000035a):

Schaut man sich die Boot Image Treiber genauer an, so erkennt man schnell einen Intel Storage Treiber.  Unter Drivers kann man ebenfalls erkennen, dass der Treiber folgende Plattformen vorgesehen ist: “All x64 Windows Server 2003 (Non R2), All x64 Windows Server 2003 R2, All x64 Windows Server 2008, All x64 Windows Vista, All x64 Windows XP Professional […]”.

Um schnell ein Zertifikat eines ADDS Servers zu überprüfen, bietet sich überraschender Weise ein Webbrowser wie der Firefox auf. Trägt man dort in der Adressleiste https://dns-name-des-domänencontrollers:636 ein. Beim Aufruf erscheint unten links das bekannte SSL-Schloss, dass man zur genaueren Inspektion nutzen kann.

Aber: Neuere Firefoxversionen verhindern https Verbindungen auf ungewöhnlichen Ports. Daher muss hier eine Ausnahme für ldaps eingetragen werden:
Um in die erweiterten Einstellungen des Firefoxes zu gelangen muss man in die Adressleiste about:config eingeben. Dort als zusätzlichen Eintrag network.security.ports.banned.override hinzufügen und als Wert den Port 636 hinterlegen (weitere Ports kann man durch Komma getrennt eingeben):