Für unsere englischen Freunde zum Gefunden werden: Windows Features fail empty list

Nun ist es hier in der Firma schon zweimal passiert. Ich muss auf einem Windows 7 x64 Rechner den IIS installieren und das geht ja bekanntlich über Windows Funktionen aktivieren/deaktivieren. Beim Aufruf erscheint ein graues leeres Fenster, das sich nach kurzer Zeit weiß färbt und das wars. Keine Anzeige der bereits installierten Windows Funktionen, keine Möglichkeit einer Interaktion.
Vor ein paar Wochen, als es das erste Mal auf einem Clientrechner aufgetaucht ist, bin ich nach dem Microsoft KB 931712 vorgegangen, d.h. man checkt mit sfc.exe /scannow durch, ob alle geschützten Systemdateien in Ordnung sind. Das war beim ersten und auch heute beim zweiten Rechner der Fall. Microsoft meint lapidar, dass man dann eben eine Systemwiederherstellung machen soll oder eben Neuinstallation. Damals hatten wir uns einvernehmlich für eine Neuinstallation entschieden und danach hat das Windows Funktionen Fenster auch wieder funktioniert.
Diesmal wollte ich mich mit dieser Lösung aber nicht zufriedengeben und habe nochmal den allwissenden Mr. Google befragt. Und ich war in der Tat erfolgreich: In einem Blog fand ich die Anleitung zu einer anderen Lösung, die zugegebenermassen ein wenig kompliziert und aufwändig war, aber letztendlich erfolgreich, Juchu!
Man installiert das System Update Readiness Tool von Microsoft, dass wohl auch alle Systemdateien checkt und die Probleme auch rausloggt. Mit diesem Log bewaffnet kann man dann in der Registry sein Unwesen treiben und die problematischen Sachen einfach löschen.
Ausführlich Anleitung in angelsächsisch hier: http://www.raymond.cc/blog/archives/2009/03/06/fix-blank-or-empty-list-in-vista-turn-windows-features-on-or-off-optionalfeaturesexe/

Ach ja: der Fehler tritt wohl so auch bei Vista auf und kann mit der gleichen Lösung behoben werden.

This made my day!

VMWare Converter Services sind eine nette Sache: Einfach mal auf einen Domaincontroller loslassen und schon hat man eine nette Kopie, die man dann unter VMWare Server laufen lassen kann und mit der man dann jede Menge Schweinereien ausprobieren kann.
Aber natürlich in einem abgeschotteten Netz (Host-Only), damit kein Unsinn mit dem echten Netz passiert (Stichwort 2 DCs mit gleichen Namen und GUID, aua aua).
Nun hat ein Host-Only-Netz meistens einen anderen IP-Range, d.h. man muss die IP-Adresse des virtualisierten DCs ändern. Dies wird auch im Netz hinlänglich beschrieben, jedoch ist bei mir immer folgendes Problem aufgetreten: Weil der DC auch gleichzeitig DNS-Server ist (AD-integriert), muss man natürlich jede Menge Einträge aktualisieren (manuell oder per Kommandozeileoperationen).
Und anfangs hat ein nslookup auf den DC auch immer die “neue” IP des DC ausgespuckt, jedoch nach einigen Minuten dann plötzlich wieder die “alte”. Natürlich war die neue IP fest auf das Interface eingetragen und die Einträge im DNS waren auch entsprechend abgeändert. Jedoch wie von Geisterhand war dann im DNS die Einträge für den DC wieder auf die alte Adresse umgeschrieben.
Nachdem ich daran schon fast verzweifelt bin, hat sich herausgestellt, dass ich das Umschreiben der IP von neu auf alt auch durch ein Neustarten des DNS-Services provozieren kann.
Das brachte mich dann auf die Idee, die Registry zu durchsuchen und in der Tat findet man dort unter HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters einen Eintrag namens PublishAddresses, der noch auf die alte IP gesetzt war. Und nach dem umbenennen, sind die Geisterhand-Änderungen Geschichte.