Archiv für Februar 2010

Windows Server 2003 AD und Windows 7 Gruppenrichtlinien

Mit der Einführung von Windows Vista hat Microsoft das proprietäre ADM-Format für administrative Vorlagen auf das XML-basierte ADMX/ADML-Format umgestellt. Gruppenrichtlinien für Windows Vista und Windows 7 lassen sich deshalb mit der Group Policy Management Console von Windows Server 2003 nicht verwalten. Was aber, wenn man noch ein Active Directory auf Basis von Windows Server 2003 betreibt und neben Windows XP auch Clients mit Windows 7 einsetzen möchte? Können neuere Komponenten wie die Windows Firewall mit erweiterter Sicherheit trotzdem über Gruppenrichtlinien administriert werden?

Kurz und knapp: Ja – das Zauberwort heißt RSAT (Remote Server Administration Tools). Mit den Remoteserver-Verwaltungstools lassen sich bestimmte Funktionen eines Windows Servers von einer normalen Arbeitsstation aus verwalten. Unter anderem enthalten sie ein Programm zur Gruppenrichtlinienverwaltung, mit dem sich die neuen Gruppenrichtlinien von Windows Vista und Windows 7 konfigurieren und mit einem Objekt im Active Directory verknüpfen lassen.

Nach Download und Installation der Verwaltungstools für Windows 7 muss das Tool zur Gruppenrichtlinienverwaltung wie folgt aktiviert werden:

  1. Start -> Systemsteuerung -> Programme -> Programme und Funktionen
  2. Windows-Funktionen ein- oder ausschalten -> Remoteserver-Verwaltungstools
  3. Featureverwaltungstools -> Tools für die Gruppenrichtlinienverwaltung

Im Gegensatz zu ADM ermöglicht das ADMX-/ADML-Format außerdem die Verwendung eines zentralen Speicherorts für alle Richtliniendateien. So ist sichergestellt, dass bei Bearbeitung der Richtlinien immer dieselbe Quelle verwendet wird. Als Best Practice sollte deshalb bereits vor der ersten Bearbeitung der Richtlinien mittels RAST ein entsprechender Speicherort angelegt werden. Zunächst wird dafür der Ordner PolicyDefinitions an folgendem Ort im SYSVOL-Verzeichnis der Domäne erstellt:

    \\FQDN\SYSVOL\FQDN\policies\

Anschließend wird der gesamte Inhalt des lokalen Ordners C:\Windows\PolicyDefinitions von der Windows 7 Installation in das zentrale Verzeichnis kopiert.

Wird der zentrale Speicher verwendet, sollte im Tool zur Gruppenrichtlinienverwaltung beim Anklicken einer administrativen Vorlage unter „Einstellungen“ die Information „Richtliniendefinitionen (AMDX-Dateien) wurden aus dem zentralen Speicher abgerufen“ angezeigt werden:

Weitere Informationen zur Verwendung des zentralen Speicherorts finden sich im KB-Artikel 929841 bei Microsoft sowie im Blogeintrag „Best Practice bezüglich aktueller ADMX / ADML Dateien“ (Technet).

Anschließend steht der Erstellung und Bearbeitung von Gruppenrichtlinien für Windows Vista und Windows 7 nichts mehr im Weg. Entsprechende Richtlinien werden dabei wie gewohnt im SYSVOL-Verzeichnis der Domäne abgelegt und von den Clients verarbeitet – unabhängig von der Version des Active Directorys.

Nebenbei: Wer unter Windows 7 ein gpresult /v ausführt und sich wundert, dass dabei keine Computereinstellungen angezeigt werden: Die Ursache liegt am Fehlen von Rechten. Wird die Eingabeaufforderung als Administrator ausgeführt, werden die Ergebnisse ordnungsgemäß angezeigt.

Advertisements

VMware ESXi 4: „Unable to access file […] since it is locked“ beim Starten einer virtuellen Maschine

Beim Hochfahren einer virtuellen Maschine auf einem Host mit VMware ESXi 4.0 U1 kam es heute zu folgender Fehlermeldung:

Zur Behebung von Problemen im Zusammenhang mit VMFS-Locking sind im VMware KB-Artikel 10051 „Virtual machine does not power on because of missing or locked files“ verschiedene Lösungsansätze beschrieben. Da für die aufgeführten Schritte allerdings zwingend der Zugriff auf die Service Console erforderlich ist, bezieht sich der Artikel unter „Product Versions“ ausschließlich auf ESX- und nicht auf ESXi-Server. Was also tun, wenn man statt ESX Systemen ESXi einsetzt und keine Service Console zur Verfügung steht?

Keine Panik, denn glücklicherweise besitzen auch ESXi-Hosts eine versteckte und funktionsreduzierte Service Console, die folgendermaßen aufgerufen werden kann:

  1. An der Konsole des ESXi-Servers ALT+F1 drücken
  2. Eingeben: unsupported
  3. Unter „Password“ das Root-Passwort eingeben

Neben der lokalen Anmeldung ist außerdem die Einrichtung von SSH möglich. Nach erfolgreicher Authentifizierung sollte die Eingabeaufforderung erscheinen:

Password:
You have activated Tech Support Mode.
The time and date of this activation have been sent to the system logs.

Tech Support Mode is not supported unless used in consultation
with VMware Tech Support.

VMware offers supported, powerful system administration tools.  Please
see www.vmwrare.com/go/sysadmintools for details.

Tech Support Mode may be disabled by an administrative user.
Disabling requires a reboot of the system.  Please consult the ESXi
Configuration Guide for additional important information.

~ #

Zurück zum eigentlichen Problem. Zunächst muss herausgefunden werden, welche Datei überhaupt gesperrt ist. Dazu wird in der Logdatei der virtuellen Maschine (hier: „vmdr“) nach entsprechenden Einträgen gesucht:

~ # grep -i "lock" /vmfs/volumes/eva03_lun4_r5/vmdr/vmware.log

Feb 11 14:33:26.290: vmx| DISKLIB-VMFS  : "/vmfs/volumes/4b0ac4f1-31aa9565-6c7e-0025b32088fc/vmdr/vmdrthin-flat.vmdk" : failed to open (Failed to lock the file): AIOMgr_Open failed. Type 3
Feb 11 14:33:26.290: vmx| DISKLIB-LINK  : "/vmfs/volumes/4b0ac4f1-31aa9565-6c7e-0025b32088fc/vmdr/vmdrthin.vmdk" : failed to open (Failed to lock the file).  
Feb 11 14:33:26.290: vmx| DISKLIB-CHAIN : "/vmfs/volumes/4b0ac4f1-31aa9565-6c7e-0025b32088fc/vmdr/vmdrthin.vmdk" : failed to open (Failed to lock the file).
Feb 11 14:33:26.290: vmx| DISKLIB-LIB   : Failed to open '/vmfs/volumes/4b0ac4f1-31aa9565-6c7e-0025b32088fc/vmdr/vmdrthin.vmdk' with flags 0xa (Failed to lock the file).
Feb 11 14:33:26.290: vmx| DISK: Cannot open disk "/vmfs/volumes/4b0ac4f1-31aa9565-6c7e-0025b32088fc/vmdr/vmdrthin.vmdk": Failed to lock the file (16392).
Feb 11 14:33:26.290: vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file.----------------------------------------

Wie im Logfile zu sehen (rot markiert), handelte es sich bei der gesperrten Datei um die virtuelle Fesplatte vmdrthin.vmdk bzw. vmdrthin-flat.vmdk.

Im zweiten Schritt wird geprüft, ob die Datei möglicherweise von einem anderen ESXi-Host im Cluster gesperrt ist:

~ # vmkfstools -D /vmfs/volumes/4b0ac4f1-31aa9565-6c7e-0025b32088fc/vmdr/vmdrthin.vmdk

Der ausgeführte Befehl schreibt die MAC-Adresse des ESXi-Hosts, der die Datei aktuell sperrt, in die Logdatei /var/log/messages (im Gegensatz zu /var/log/vmkernel bei ESX):

Feb 11 14:23:48 vmkernel: 35:01:22:30.577 cpu4:17213713)FS3: 142: 
Feb 11 14:23:48 vmkernel: 35:01:22:30.577 cpu4:17213713)Lock [type 10c00001 offset 56178688 v 92, hb offset 3764224
Feb 11 14:23:48 vmkernel: gen 6623, mode 0, owner 00000000-00000000-0000-000000000000 mtime 64182]
Feb 11 14:23:48 vmkernel: 35:01:22:30.577 cpu4:17213713)Addr , gen 40, links 1, type reg, flags 0x0, uid 0, gid 0, mode 600
Feb 11 14:23:48 vmkernel: 35:01:22:30.577 cpu4:17213713)len 527, nb 1 tbz 0, cow 0, zla 2, bs 65536
Feb 11 14:23:48 vmkernel: 35:01:22:30.577 cpu4:17213713)FS3: 144: 

In diesem Fall hatte die MAC-Adresse (wieder rot markiert) den Wert 000000000000 – offenbar wurde die Datei also von keinem anderen ESXi-Host gesperrt.

Im nächsten Schritt wird durch Überprüfung aller VM-Konfigurationsfiles festgestellt, ob die VMDK-Datei möglicherweise noch von anderen virtuellen Maschinen verwendet wird:

~ # egrep -i vmdrthin.vmdk /vmfs/volumes/*/*/*.vmx

/vmfs/volumes/4b0ac4f1-31aa9565-6c7e-0025b32088fc/vmdr/vmdr.vmx:scsi0:0.fileName = "vmdrthin.vmdk"
/vmfs/volumes/4b0ac4f1-31aa9565-6c7e-0025b32088fc/vmdr/vmdr.vmx:scsi0:1.fileName = "vmdrthin.vmdk"
/vmfs/volumes/eva03_lun4_r5/vmdr/vmdr.vmx:scsi0:0.fileName = "vmdrthin.vmdk"
/vmfs/volumes/eva03_lun4_r5/vmdr/vmdr.vmx:scsi0:1.fileName = "vmdrthin.vmdk"

Und siehe da: Die virtuelle Maschine „vmdr“ enthielt zwei Einträge zur selben VMDK-Datei! Das kann natürlich nicht funktionieren und erklärt die Fehlermeldung: Unmittelbar nach dem Einschalten der VM war die VMDK-Datei gesperrt und konnte kein zweites Mal geöffnet werden.

Weiterhin erklärt es den Wert 00000000000 bei der Suche nach der MAC-Adresse des sperrenden Hosts: Da die VM unmittelbar nach Ausgabe der Fehlermeldung wieder ausgeschaltet wurde, war die Datei zum Zeitpunkt der Suche einfach nicht mehr gesperrt.

Nach Korrektur der Konfiguration im vSphere Client ließ sich sich virtuelle Maschine wieder problemlos starten. Also: Augen auf beim Hinzufügen von virtuellen Festplatten!