Archiv für August 2010

Fehler beim Erstellen eines Windows 7 Images mit Sysprep

Im Rahmen des Rollouts von Windows 7 für 30 Computer musste ich mich letzte Woche das erste Mal mit der Erstellung eines Images von Windows 7 beschäftigen. Genau wie früher (Windows XP) kann das Betriebssystem auch heute noch mit Sysprep entsprechend vorbereitet werden. Eine Antwortdatei wird dagegen nicht mehr mit dem kleinen Programm „Setup Manager“, sondern dem „Windows System Imager“ aus dem Windows Automated Installation Kit (AIK) erzeugt. Allerdings will ich das hier nicht beschreiben, sondern lediglich auf zwei Fehler eingehen, mit denen ich während der Vorbereitung konfrontiert war. Grundlegende Anleitungen gibt es ansonsten hier und hier.

Der erste Fehler – „Schwerwiegender Fehler bei der Systemvorbereitung des Computers“ – trat während der Ausführung von Sysprep auf:

Bei der Fehlersuche stößt man zunächst auf ein Problem im Zusammenhang mit dem Windows Media Player-Netzwerkfreigabedienst. Bei mir trat der Fehler allerdings nicht von Anfang an auf, sondern erst nach mehrmaligem Ausführen von Sysprep am selben Image. Der Fehler wird in diesem Fall nicht durch den genannten Dienst verursacht, sondern durch das zu häufige Zurücksetzen der Produktaktivierung. Das Verhalten ist bei Microsoft im Knowledgebase Artikel 929828 beschrieben.

Der zweite Fehler trat im Rahmen der Anpassung des Default User Profiles auf. Unter Windows 7 kann das Standardprofil nur noch mittels Sysprep gecustomized werden. Hierfür passt man mit einem lokalen Konto die Benutzereinstellungen entsprechend an und führt anschließend Sysprep mit dem CopyProfile Parameter aus. Dies bewirkt, dass die Einstellungen des aktuellen Profiles (zumindest teilweise) auf das Default User Profile angewendet werden. Genauere Informationen gibt es im Knowledgebase Artikel 973289 und im Technet Artikel Customizing Default users profile using CopyProfile.

Beim ersten Booten nach Ausführen von Sysprep + CopyProfile kam es allerdings zu folgender Fehlermeldung:

Und nach dem zweiten Neustart ging es nur noch bis zu diesem Fenster und anschließend nicht mehr weiter:

Das Problem trat deshalb auf, weil die Liste der Profile in der Registrierung unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList nicht mit dem Inhalt des Verzeichnisses C:\Users bzw. C:\Benutzer übereingestimmt hat. Während der Installation hatte ich einen lokalen Benutzer angelegt und später wieder gelöscht – inkl. Löschen des Profilverzeichnisses. Der Eintrag in der Registry war aber noch vorhanden.

Nach Entfernen des Eintrags und erneutem Ausführen von Sysprep + CopyProfile ließ sich Windows erfolgreich hochfahren und die zuvor definierten Einstellungen wurden wie erwartet auf das Default User Profile angwendet.

Advertisements

Nur noch ein LUN Managing Controller auf einer EVA 4400?

Auch wenn die Vdisks bzw. LUNs einer EVA 4400 über beide Controller erreichbar sind, so können I/O Requests tatsächlich immer nur von einem – dem LUN Managing Controller – ausgeführt werden:

    When creating a virtual disk, one controller is selected to manage the virtual disk. Only this managing controller can issue I/Os to a virtual disk in response to a host read or write request. If a read I/O request arrives on the non-managing controller, the read request must be transferred to the managing controller for servicing. The managing controller issues the I/O request, caches the read data, and mirrors that data to the cache on the non-managing controller, which then transfers the read data to the host. Because this type of transaction, called a proxy read, requires additional overhead, it provides less than optimal performance. (There is little impact on a write request because all writes are mirrored in both controllers’ caches for fault protection.) [1]

Bei mehreren Vdisks möchte man diese also nach Möglichkeit gleichmäßig über beide Controller verteilen. Festgelegt wird das mittels der Einstellung „Preferred path/mode“ in den Eigenschaften der Vdisk in Command View. Path-A-Failover setzt den Managing Controller der Vdisk auf Controller 1, Path-B-Failover auf Controller 2.

Dabei gibt es noch eine Besonderheit zu beachten: Implicit LUN Transition. Wird der Großteil der Read Requests über den Non-Manging Controller empfangen, wird die Vdisk entsprechend verschoben:

    With implicit LUN transition, when the array detects that a majority of read requests for a virtual disk are proxy reads, the array transitions management of the virtual disk to the non-managing controller. This improves performance because the controller receiving most of the read requests becomes the managing controller, reducing proxy read overhead for subsequent I/Os. [1]

Je nach Konfiguration des angeschlossenen Hosts kann sich der Managing Controller einer Vdisk also nachträglich ändern.

Obwohl unsere Vdisks mittels der „Preferred path/mode“ Option auf beide Controller aufgeteilt sind, hatten wir seit einigen Wochen das Problem, dass nur noch Controller 1 als Managing Controller verwendet werden konnte. Kurz nach dem manuellen Festlegen von Controller 2 wurde die Konfiguration zwar übernommen, innerhalb von wenigen Sekunden aber wieder zurück auf Controller 1 geändert.

An der Implicit LUN Transition konnte das nicht liegen. Erstens wechselt diese den Controller nicht schon nach wenigen Sekunden und zweitens trat das Problem auch dann auf, wenn auf einem Host z.B. nur ein fester Pfad zu Controller 2 konfiguriert war.

Verursacht wird das Problem durch einen Firmwarefehler, der zu einem falschen Status der Cache Batterien führen kann. Der betroffene Controller verliert in diesem Fall alle LUN Ownerships und überträgt diese an den anderen Controller. Ersichtlich wird dies durch entsprechende Meldungen im Controller Event Log:

Neben einer sehr großen Anzahl an „An HSV300 controller has changed Battery Cache policy“ Ereignissen hat zumindest in unserem Fall (XCS 09522000) zusätzlich die linke Status LED von Batterie 1 (Controller 2) grün geblinkt (Maintenance in progress).

Beheben lässt sich das Verhalten durch einen Reboot des betroffenen Controllers. Verhindert wird es durch das Firmwareupdate auf XCS 0953400, in dessen Release Notes das Problem auch aufgeführt ist:

    Added a verification step to ensure that an accurate cache battery state is returned for HSV300 controllers to avoid falsely triggered cache policy changes.

Nach dem ersten Reboot von Controller 2 mittels WOCP blieb dieser beim Starten übrigens hängen und ließ sich erst nach einem Reseat (kurz rausziehen und wieder einstecken) wieder booten. Man sollte dabei also besser vor Ort sein.

Ich bin gespannt, ob und nach welcher Zeit das Problem wieder auftritt. Ansonsten ist das Update auf XCS 0953400 natürlich schon geplant.

[1] HP StorageWorks 4400 Enterprise Virtual Array user guide