In diesem Artikel wird beschrieben, wie eine Failed VM in Virtual Machine Manager repariert werden kann. Dieses Troubleshooting, auch als “Notes from the field” bekannt, sollte auch aufzeigen wie ein Problem in VMM analysiert werden kann… Zur Situation: Bei einer von VMM verwaltete Virtual Machine wurde jeder Job / jede Änderung abgebrochen. Im Job-Log wurde folgende Fehlermeldung ausgegeben:

Error (12711)
VMM cannot complete the WMI operation on server MyDamagedVM.intra.server-talk.eu because of error: [MSCluster_ResourceGroup.Name="dced5bf8-493b-49b7-8295-ee079d008b1f"] The cluster group could not be found.
(The cluster group could not be found (0×1395))

Recommended Action
Resolve the issue and then try the operation again.

Die Virtual Machine wird in Virtual Machine Manager mit dem Status Failed dargestellt. Ist die VM gestartet, läuft diese zwar uneingeschränkt weiter, allerdings könne in VMM keine  Aktionen mehr ausgeführt werden, selbst die Funktion “Repair” schlägt fehl…

(weiterlesen…)

Diese Woche hat Nils Kaczenski von faq-o-matic.net ein Artikel zu “LUN auswerfen?!” gepostet. Bei näherer Betrachtung hat sich herausgestellt, dass dieser Server virtuell betrieben wird und die LUNs als Wechselhardware angezeigt werden. Da dies bei manchen Servern sehr unangenehm sein kann, wenn ein Laufwerk einfach so entfernt würde, schauen wir uns die Ursache mal etwas genauer an…

Bei Hyper-V werden Datenträger entweder an einen IDE- oder SCSI-Controller angeschlossen. Da man mit SCSI weitaus eine grössere Zahl von Devices verwalten kann, sowie auch im laufenden Betrieb ohne downtime weitere Hard Disks hinzugefügt werden können, wird empfohlen für Daten Disks ausschliesslich den SCSI-Controller zu verwenden. Auch Pass-through Disks werden mit einem SCSI-Controller konfiguriert.

Nun ist es so, dass alle Hard Disks welche an einem solchen SCSI-Controller angeschlossen sind, als auswerfbar angezeigt werden. Mit einem Klick auf das Task Icon “Safely Remove Hardware and Eject Media” lässt sich die Disk auswerfen (“Eject Msft Virtual Disk SCSI Disk Device”):

Was passiert nun, wenn eine Hard Disk ausgeworfen wurde? Windows Server führt diese Aktion entsprechend durch und die Disk wird auch aus dem Storage Manager entfernt. Diese bleibt solange “verschwunden” bis a) der Server neu gestartet wird, oder b) die VHD in den Virtual Machine Settings re-attached wird. Übrigens, da IDE Hard Disks, wie zum Beispiel auch die System Disk, nicht online hinzugefügt werden können, werden diese Laufwerke auch nicht als auswerfbar angezeigt.

Ironischerweise ist die Anzeige im Device Manager korrekt und die Hard Disk wird nicht als “Devices with removable storage” aufgeführt:

Dieses Verhalten ist auch bei Windows Server 2008 R2 (Beta) mit installiertem Service Pack 1 noch so. Workaround? Eigentlich kein richtiger – “Safely Remove Hardware and Eject Media” kann zum Beispiel von der Taskbar ausgeblendet werden…

By the way – auch bei VMware werden Devices zum Auswerfen angezeigt:

Der Core Installation Mode (Server Core) ist sehr häufig mit Hyper-V und natürlich bei Hyper-V Server anzutreffen. Durch die geringe Angriffsfläche, Wartungs- und Verwaltungsaufwand ist dies die ideale Konfiguration. Ein sicheres System ist nicht immer die einfachste Variante – gerade die Installation von NIC Treiber und/oder Teaming Software ist bei Server Core aufwändiger als bei einer Installation im Full Installation Mode, aber durchaus machbar.

In gewissen Konstellationen kann es vorkommen / angebracht sein – nicht verendete Network Adapter zu deaktivieren. Bei Server Core wird dies mit dem Netsh Command-Line Utility durchgeführt: “netsh interface set interface "Local Area Connection 4" DISABLED. Der Status der Network Adapter kann mittels “netsh interface show interface” überprüft werden.

Es kann allerdings nachträglich zu Problemen kommen, diesen Adapter wieder zu aktivieren. Zum Beispiel nach einem Update der Treiber (zum Beispiel bei Broadcom in HP Server…). Der Status bleibt dann auch nach der Anwendung von Netsh “Disabled”. Ein simples WMI-Script kann hier Abhilfe leisten:

Function EnablePreviouslyDisabledNics()
    strComputer = "."
    Set objWMIService = GetObject("winmgmts:\\" & _
    strComputer & "\root\cimv2")
    Set colAdapters = objWMIService.Execquery("Select * from Win32_NetworkAdapter Where NetEnabled=False")
    For Each Adapter in colAdapters
        Adapter.Enable()
    Next
    Set objWMIService = Nothing
End Function

EnablePreviouslyDisabledNics

Einfach als enableNIC.vbs speichern und auf dem Server aufrufen, “cscript enableNIC.vbs“. Sämtlich deaktivierten Network Adapter werden nun wieder aktiviert und der können wieder verwendet werden. Mit “netsh interface show interface” kann wieder der Status überprüft werden.

Weitere Informationen

• Microsoft TechNet: Netsh Commands for Interface (IPv4 and IPv6)

Microsoft empfiehlt für den produktiven Einsatz von Hyper-V den Core Installation Mode zu wählen. Denn die Vorteile des Server Core liegen für die Virtualisierung eigentlich ganz klar auf der Hand:

• Wartung - Da bei einer Server Core Installation nur das installiert wird, was zur Verwaltung einer Rolle erforderlich ist, fällt weniger Wartungsaufwand an.
• Angriffsfläche – Systemdateien sind nur in minimalem Umfang installiert. Dadurch dass nur wenige Dienste und Anwendungen laufen, verringert dies die Angriffsfläche.
• Management - Da auf einem Server im Core Installation Mode nur wenige Applikationen und Dienste vorhanden sind, sinkt der Verwaltungsaufwand.
• Speicherplatzbedarf – Server Core benötigt zur Installation nur etwa 1 Gigabyte (GB) Disk Space. Im Anschluss daran sind beim Betrieb lediglich rund 2 GB erforderlich.

Wie die Installation von Hyper-V auf Basis von Server Core durchgeführt werden kann, wird in einem älteren Artikel bereits beschrieben. Mit dem in Windows Server 2008 R2 hinzugefügten “sconfig” geht dies  inzwischen ganz flott. Nun hat sich herausgestellt, dass bei manchen ProLiant Server von HP zu Problemen kommen kann. Beim Anlegen des Failover Cluster wird folgende Fehlermeldung angezeigt:

An error occurred while creating the cluster. An error occurred creating cluster ‘clustername’.
The service has not been started.

(weiterlesen…)

Mit Hyper-V ist es möglich einer Virtual Machine mehrere Prozessoren zuzuweisen. Dies wird auch als “Symmetric Multiprocessing” oder kurz “SMP” bezeichnet. Vom Hypervisor werden in der Version 2008 R2 Konfigurationen mit 1, 2, 3 und 4 Virtuellen Prozessoren unterstützt. Je nach Betriebssystem unterscheidet sich allerdings die Anzahl der Prozessoren, welche durch Microsoft supported wird:

• Windows Server 2008 (R2): 1, 2, oder 4 Virtuelle Prozessoren
• Windows Server 2003 mit Service Pack 2: 1, oder 2 Virtuelle Prozessoren
• Windows 2000 Server mit Service Pack 4: 1 Virtueller Prozessor

Technisch gesehen können natürlich auch Virtual Machines mit mehr als 1, oder 2 Virtuellen Prozessoren konfiguriert werden. Das Betriebssystem wird dies auch entsprechend identifizieren, allerdings wurde diese Konfiguration, zum Beispiel für Windows Server 2003, nicht durch Microsoft getestet und ist daher auch nicht supported. Bei einer Störung muss das Problem zunächst bei einer Virtual Machine mit 2 Prozessoren reproduziert werden können.

(weiterlesen…)

Mit Windows Virtual PC (VPC) und dem neuen Tool Disk2VHD von Sysinternals wurde ein kleiner Hype entfacht, wobei viele Administratoren versucht haben, ihren persönlichen Computer in eine Virtual Machine zu konvertieren. In Zeiten von Hard Disks im Terrabyte Bereich wurde die Euphorie schnell von einer Limitation in Virtual PC gebremts. Denn VPC kann mit Virtual Hard Disks (VHDs) grosser als 127.5 GB nicht umgehen. Der Vorgang eine solches VHD Image in hinzuzufügen wird mit folgender Fehlermeldung abgebrochen:

The virtual hard disk image ‘.\My Virtual Machines\WS2008.vhd’ is too large for the IDE bus. Make sure that all virtual hard disk images connected to the IDE bus are not greater than 127.5 GB.

Für ein Resize eines solchen VHD Image, kann nicht nur die Virtual Hard Disk verkleinert werden. Auch die darauf angelegten Volumes müssen vorgängig auf die neue Grösse angepasst, sprich verkleinert werden.

Resize Volume

Das Volume kann auf einem Host System wie Windows 7, oder Server 2008 R2 sehr einfach verkleinert werden. Dazu muss lediglich ein Command Prompt als Administrator geöffnet und Diskpart ausgeführt werden. Nachdem eine Virtual Hard Disk geladen / attached wurde kann bereits das gewünschte Volume verkleinert werden. Sinnvoll ist es das Volume vor der Konvertierung zu defragmentieren, da ansonsten zu viel verteilter Speicherplatz belegt wird. Im nachfolgenden Beispiel wird ein Volume vom VHD Image “TestW7.vhd” auf 100 GB verkleinert:

DISKPART> list vdisk
DISKPART> select vdisk file=D:\TestW7.vhd
DISKPART> attach vdisk
DISKPART> list volume
DISKPART> select volume 4
DISKPART> shrink desired=102400
DISKPART> detach vdisk
DISKPART> exit

Wird bei “shrink” kein spezifischer Wert angegeben (desire=), so wird automatisch der maximal mögliche Wert genommen.

Resize VHD Image

Im nächsten Schritt muss auf das Tool VHD Resizer zurückgegriffen werden. Der VHD Resizer kopiert den Inhalt eines VHD Image blockweise in eine neue Datei. Der Vorteil hierbei ist, dass das Original Image erhalten bleibt und somit keine Daten verloren gehen (sollten). Damit die “Volume ID” nicht verändert wird, muss zwingend eine Kopie auf Blocklevel durchgeführt werden.

Die Handhabung von VHD Resizer ist einfach, nach der Installation muss lediglich das Source und Target VHD Image, sowie die neue Grösse (maximal 127 GB) angegeben werden, damit der Kopiervorgang gestartet werden kann. Ist die Datei allerdings zu diesem Zeitpunkt noch im Zugriff durch eine andere Applikation wie VPC, oder Disk Management, so wird die Meldung “Invalid Disk, please select another” ausgegeben.

Die Konvertierung in das neue VHD Image wird mit “Resize complete, resize another” abgeschlossen. Das Tool schliess sich übrigens automatisch, wenn “no” angewählt wird… Danach kann das neu angelegte Image der entsprechenden Virtual Machine hinzugefügt werden.

Source

Die Source für VHD Resizer kann direkt bei vmToolkit heruntergeladen werden, zum Download… Wichtig! Natürlich gibt es andere Lokationen welche weitere Downloads anbieten, es sollte allerdings nur offizielle Builds und Download Centers aufgesucht werden. Zitat Forrest Gump: “Man weiss nie, was man kriegt.”

• Version: 1.0.42
• Date Published: 2007-01-18
• Language: Englisch
• Format: *.msi
• Publisher: vmToolkit
• License: Freeware

Weitere Informationen

• Server Talk: Sysinternals “Disk2vhd”
• Server Talk: How-To: Resize von VHD Files

Die Installation von Windows mittels USB-Drive ist gerade in der aktuellen Zeit sehr beliebt, da Windows 7 und Windows Server 2008 R2 released wurden. Wie ein solches Device erstellt werden kann, wird im Artikel “How-To: Install Windows Server 2008 R2 von USB-Drive” beschrieben.

Wird nun aber der Bootvorgang mit einem Fehler abgebrochen muss ein USB-Drive / -Stick unter Umständen bootbar gemacht werden. Beim Lenovo Thinkpad X301 oder T500 wird beispielsweise folgende Meldung angezeigt:

Invalid or damaged bootable partition

Für diesen Vorgang wird das Tool “bootsec.exe” aus dem Windows Installationsmedium benötigt. Mit Bootsect.exe wird der Master Boot Code von Festplattenpartitionen für den Wechsel zwischen BOOTMGR und NTLDR aktualisiert. Mithilfe dieses Tools kann der Bootsektor auf einem Computer wiederhergestellt werden. Damit werden die Tools FixFAT und FixNTFS ersetzt.

Um nun diesen Master Boot Code zu schreiben muss mit einem Command Prompt (als Administrator ausführen) in das Verzeichnis \boot gewechselt werden. Mit dem Befehl bootsect /nt60 e: /mbr wird dann der Bootcode geschrieben. In dem gezeigten Beispiel repräsentiert E: das USB-Drive welches bootbar gemacht werden soll. Die Version des Installationsmediums, respektive die Version von bootsec.exe, muss der Architektur des Host Betriebssystem entsprechen. Ansonsten wird folgende Fehlermeldung ausgegeben:

This version of E:\boot\bootsect.exe is not compatible with the version of Windows you’re running. Check your computer’s system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

In anderen Worten: Wird dieser Vorgang auf einem Windows 7 64-Bit Edition ausgeführt, muss auch .\boot\bootsec.exe von einem 64-Bit Medium ausgeführt werden. 

Nach erfolgreichem Update wird eine entsprechende Meldung ausgegeben:

D:\ISO\en_windows_7_enterprise_x64\boot>bootsect /nt60 e: /mbr
Target volumes will be updated with BOOTMGR compatible bootcode.

E: (\\?\Volume{df4627d5-2a5c-11de-bcde-806e6f6e6963})
    Successfully updated FAT32 filesystem bootcode.

\??\PhysicalDrive1
    Successfully updated disk bootcode.

Bootcode was successfully updated on all targeted volumes.

Nicht vergessen, vor einer Installation immer fleissig die Daten sichern. Ein dafür geeignetes Tool mit entsprechendem Online Storage ist MozyHome (2.2GB for free). Happy staging…!

Weitere Informationen

• Microsoft TechNet: Bootsect Command-Line Options

Es kann durchaus mal vorkommen, dass sich eine Virtual Machine so aufgehängt hat, dass sich diese nicht mehr mittels Management Console nicht mehr stoppen lässt. In einem solchen Fall kann der einzelne Virtual Machine Worker Prozess (vmwp.exe) abgeschossen werden, damit nicht der ganze Server neu gestartet werden muss.

Als Hilfsmittel dient der Windows Task Manager, oder die erweiterte Form der Sysinternals Process Explorer, ebenfalls aus dem Hause Microsoft.

1. Utility Process Explorer mit “Run as Administrator” starten und die EULA akzeptieren, zuvor natürlich auch lesen.
2. Die Ansicht in der Menu Bar mit “View | Select Columns…” anpassen damit die Spalte “Command line” im Hauptfenster angezeigt wird.
3. Aus der hinzugefügten Spalte kann nun die eindeutige Kennung einer Virtual Machine ausgelesen werden. Der Inhalt wird wie folgt dargestellt: "C:\Windows\System32\vmwp.exe" E314B8Fe-FB75-48B8-914F-E9B2362D9E0B
4. Die Zahlenfolge “E314B8Fe-FB75-48B8-914F-E9B2362D9E0B” definiert in diesem Beispiel die GUID der Virtual Machine namens “MyCrashedVM”.
5. Um den Prozess einer Virtual Machine zuweisen zu können, muss die GUID einer Virtual Machine bekannt sein. Dieser kann beim entsprechenden Verzeichnis ausgelesen werden, der Default Path lautet: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\
6. Im Sub-Folder “Virtual Machines” existiert jeweils ein XML-Document welches die eindeutige Kennung repräsentiert. In diesem Beispiel mit Cluster Shared Volume (CSV) sieht der Path wie folgt aus: C:\ClusterStorage\Volume1\MyCrashedVM\Virtual Machines\E314B8Fe-FB75-48B8-914F-E9B2362D9E0B.xml
7. Wenn die Virtual Machine GUID dem entsprechende Virtual Machine Worker Prozess zugewiesen werden konnte, kann mit einem Rechtsklick auf den entsprechenden Prozess die Funktion ”Kill process” aufgerufen und der Prozess “abgeschossen” werden.
8. Die Meldung “Are you sure you want to kill vmwp.exe” muss noch mit “Yes” bestätigt werden. Dies beendet die problematische Virtual Machine ohne die anderen Instanzen zu beeinträchtigen.
9. Nun kann die Virtual Machine mit der Hyper-V Management Console wieder gestartet werden.

Der beschriebene Vorgang kann praktisch 1: 1 auch mit dem Windows Task Manager durchgeführt werden. Mit dem Process Explorer werden die Informationen nur besser dargestellt. Wichtig, beide Tools müssen bei aktivem User Account Control (UAC) explizit als Administrator ausgeführt werden.

Ach ja, für alle Hyper-V Kritiker, einen vergleichbaren Artikel gab es auch schon für VMware ESX: How-To: Eine VMware ESX Virtual Machine “abschiessen”…

Wenn man wissen will, was auf einem Windows System läuft, ist man mit “Process Explorer” auf der richtigen Spur. Die Freeware aus dem Hause Microsoft zeigt alle Details der laufenden Prozesse minutiös an. Das Utility liefert zudem eine genaue Aufstellung darüber, welche Files aktuell geladen sind, welche Priorität diese besitzen und welche DLLs mit ausgeführt werden. Eine nettes Troubleshooting-Hilfsmittels um den Plagegeistern auf die Schliche zu kommen.

Das Utility kann zudem alles was der in Windows integrierte Task Manager auch kann. Der Process Explorer ist also sozusagen der grosse Bruder des Windows Task Managers.

About Process Explorer

Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded.

The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you’ll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you’ll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.

The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.

Support

Tools von Sysinternals kommen zwar inzwischen von Microsoft, werden allerdings als „as is“ bereitgestellt. Ein Auszug aus den Sysinternals Software License Terms:

5. SUPPORT SERVICES: Because this software is “as is,” we may not provide support services for it.

9. DISCLAIMER OF WARRANTY: The Software is licensed “as is”. You bear the risk of using it. Sysinternals gives no express warranties, guarantees or conditions. You may have additional consumer rights under your local laws which this agreement cannot change. To the extent permitted under your local laws, Sysinternals excluded the implied warranties of merchantability, fitness for a particular purpose and non-infringement.

10. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES: You can recover from Sysinternals and its suppliers only direct damages up to U.S: $5.00. You cannot recover any other damages, including consequential, lost profits, special, indirect or incidental damages.

Source

Die Source für Process Explorer kann direkt bei Microsoft TechNet heruntergeladen werden, zum Download… Wichtig! Natürlich gibt es andere Lokationen welche weitere Downloads anbieten, es sollte allerdings nur offizielle Builds und Download Centers aufgesucht werden. Zitat Forrest Gump: “Man weiss nie, was man kriegt.”

• Version: 11.33
• Date Published: 2009-02-04
• Language: English
• Format: *.zip
• Publisher: Microsoft (Sysinternals)
• License: Freeware

Das Utility Process Explorer kann übrigens auch direkt via “Live.Sysinternals.com” gestartet werden.

Es gibt einige Möglichkeiten wie Resource Mailboxen konfiguriert werden können. Mit der Delegate Einstellung können Meeting Requests direkt zur Genehmigung an eine Verwaltung, Sekretärin, oder eine andere Stelle weitergeleitet werden. Dabei gilt es allerdings zu beachten, dass in bestimmten Konstellationen diese E-Mails “nicht ankommen”…

Für die Fehlerbehebung sollte zunächst in die Exchange Management Shell gewechselt werden. Mit dem Befehl “Get-MailboxCalendarsetting” kann die aktuelle Konfiguration ausgelesen werden. Nachfolgend ein Auszug einer solchen “Problem Resource”:

ResourceDelegates : {Michel}
RequestOutOfPolicy :
AllRequestOutOfPolicy : True
BookInPolicy :
AllBookInPolicy : False
RequestInPolicy :
AllRequestInPolicy : True

Da die Optionen “AllRequestInPolicy” und “AllRequestOutOfPolicy” auf $true gesetzt sind, wird der Exchange Server dies nicht entsprechend an die Delegates weiterleiten. Wird “AllRequestOutOfPolicy” zurück auf $false gesetzt, werden die Anfragen an die Delegates weitergeleitet, that’s it…