Archiv für November 2010

Windows-Anmeldung ist an einem mittels Acronis True Image wiederhergestellten Server nicht mehr möglich

Vor wenigen Tagen war ich mit dem Problem konfrontiert, dass nach dem Restore eines mittels True Image erstellten Windows Server 2003 Images keine Anmeldung am wiederhergestellten Server mehr möglich war. Unmittelbar nach Eingabe des Windows-Kennworts wurde jeder Benutzer inkl. des lokalen Administrators sofort wieder abgemeldet.

Nach etwas Recherche stellte sich heraus, dass sich aus irgendeinem Grund die Laufwerksbuchstaben geändert hatten. Aus der Systempartition D:\ war F:\ geworden und das ursprüngliche Laufwerk F:\ trug den Buchstaben D:\. Dies führte dazu, dass Windows die für die Anmeldung erforderliche und in der Registrierung mit einem festen Pfad angegebene Systemdatei D:\Windows\system32\userinit.exe nicht mehr laden konnte und somit zum beschriebenen Problem.

Wie in Microsoft Knowledgebase Artikel 249321 beschrieben, habe ich zunächst die Ordnerstruktur Windows\system32 auf Laufwerk F:\ erstellt und dort die originale userinit.exe hineinkopiert. Nach einem Neustart funktionierte die Windows Anmeldung dann wieder.

Im nächsten Schritt habe ich die Zuordnungen der Laufwerksbuchstaben wie in Knowledgebase Artikel 223188 beschrieben wiederhergesellt, in dem ich im Registry-Schlüssel

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

zuerst den Eintrag \DosDevices\D: temporär auf \DosDevices\X:, anschließend \DosDevices\F: auf \DosDevices\D: und schließlich \DosDevices\X: auf \DosDevices\F: geändert habe.

Nach einem Neustart stimmten die Laufwerkszuordnungen wieder. Die Ursache für die Änderung habe ich allerdings nicht herausgefunden; wenn das jemand weiß, wäre ich für eine kurze Info dankbar.

Advertisements

VMware Tools & Windows XP: Gruppenrichtlinien werden beim Start nicht angewendet

Vor wenigen Tagen musste ich die Verteilung einer Software via Gruppenrichtlinie testen und habe mir dafür eine virtuelle Maschine mit Windows XP als Testsystem konfiguriert. Sofern die Fast Logon Optimization via GPO deaktiviert wurde, sollten zugewiesene Softwareinstallationen und andere auf den Computer bezogene Gruppenrichtlinien noch vor der Anmeldung des Benutzers angewendet werden.

In meinem Fall klappte das nicht. Ein gpresult /v | more zeigte keine angewandten Richtlinien und im Eventlog wurden die Ereignisse 1030 und 1097 protokolliert:

Auf den ersten Blick wunderte mich die im Protokoll beschriebene Zeitabweichung zwischen Server und Client. Zwischen den Systemen gab es keine Differenz und auch die Zeitsynchronisation zwischen VM und ESX-Host in den VMware Tools war deaktiviert – obwohl das meiner Meinung nach ohnehin keine Rolle hätte spielen dürfen, da die ESX Server ihre Zeit vom gleichen NTP-Server erhalten, wie der PDC-Emulator im Active Directory.

Umsomehr war ich verwundert, als die Probleme nach einer testweisen Deinstallation der VMware Tools trotzdem verschwunden waren. Die Gruppenrichtlinien wurden wie erwartet angewandt und auch die Fehler aus dem Eventlog waren verschwunden. Nach einer Neuinstallation der VMware Tools traten die Probleme dagegen wieder auf.

Bei einem zweiten Blick ins Eventlog stellte sich allerdings heraus, dass es beim Hochfahren tatsächlich zu einer Änderung der Uhrzeit kam. Im folgenden Bild ist zu sehen, dass die Uhrzeit um 13:22:21 Uhr für einen Zeitraum von wenigen Sekunden auf 13:11 Uhr geändert wurde:

Infolgedessen kam es also für kurze Zeit wirklich zu der protokollierten Differenz zwischen Client und Server und damit zu den beschriebenen Problemen. Dass es bei entsprechenden Abweichungen im Active Directory zu Problemen kommt, ist bekannt.

Aber warum wurde die Zeit geändert, obwohl die entsprechende Funktion in den VMware Tools deaktiviert war? Die Ursache dafür verbirgt sich in VMware KB-Artikel 1189: Disabling Time Synchronization:

    The time synchronization checkbox controls only whether time is periodically resynchronized while the virtual machine is running. Even if this box is unselected, VMware Tools by default synchronizes the virtual machine’s time after a few specific events that are likely to leave the time incorrect.

Auch wenn die entsprechende Checkbox in den VMware Tools deaktiviert ist, wird also nach bestimmten Ereignissen trotzdem eine Zeitsynchronisation mit den ESX-Servern durchgeführt. Dazu gehört unter anderem auch ein Neustart des VMware Tools Service und damit auch ein Neustart der VM.

Die Ursache für die Abweichung von elf Minuten war ebenfalls schnell geklärt: Entgegen meiner Meinung war auf dem entsprechenenden ESX-Server gar kein NTP Server konfiguriert und die Uhr ging schlicht nach. Das war letztlich auch die Lösung des Problems: Nach Konfiguration des NTP-Servers führte die automatische Zeitsynchronisation beim Starten der VM zu keiner Abweichung mehr und die Richtlinien wurden erfolgreich angewandt.