Ich hatte das Problem, dass bei einem Windows 7 System der Schlüssel „HKEY_CURRENT_USER\Software\Classes“ nicht zugänglich war. Aufgefallen ist das aber erst bei der Installation eines neuen Programms. Da ich wegen der Fehleranalyse sowieso schon den Process Monitor von Sysinternals angeworfen hatte, dache ich mir, das Problem wirst du jetzt lösen.

Zunächst aber ein paar Hintergrundinformationen:

„HKEY_CURRENT_USER\Software\Classes“ ist kein Registry-Schlüssel sondern ein Registry-Link, der beim Anmelden des Benutzers durch die „Winlogon.exe“ erzeugt wird. Das kann man ganz leicht nachprüfen, da sich in der Datei „ntuser.dat“ (ruhig mal von einem anderen Account aus als Hive laden) dieser Schlüssel nicht befindet.

Der Registry Link „HKEY_CURRENT_USER\Software\Classes“ zeigt eigentlich auf „HKEY_USERS\<user-SID>_Classes“. „HKEY_USERS\<user-SID>_Classes“ wiederum kommt aus der Datei „%userprofile%\AppData\Local\Microsoft\Windows\UsrClass.dat“.

Nun also zurück zu meinem Problem:
Bei meinem Benutzeraccount fehlten sämtliche Unterschlüssel von „HKEY_CURRENT_USER\Software\Classes“. Der Schlüssel „HKEY_USERS\<user-SID>_Classes“ für diesen Benutzer war aber vorhanden und konnte mit einem administrativen Account eingesehen werden.

Ich vermutete ein Rechte-Problem und habe (während ich mit Process Monitor die Registry auf ACCESS_DENIED prüfte) einfach mal im Schlüssel „HKEY_USERS\<user-SID>_Classes“ versucht, die Berechtigungen komplett durchzuvererben.

Tatsächlich spuckte der Process Monitor bei einigen Schlüsseln einen „ACCESS_DENIED“-Fehler aus. In meinem Fall waren es einige Schlüssel unterhalb von „HKEY_USERS\<user-SID>_Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node“.

Für die betroffenen Schlüssel musste ich zunächst den Besitz übernehmen und dann die Rechte abändern. Zum Schluss lief dann die Rechtevererbung ohne Fehler durch und der Process Monitor zeigte auch keine Probleme mehr an.

Zusätzlich habe ich noch überprüft, ob der Benutzer überhaupt Schreibrechte für die Datei „%userprofile%\AppData\Local\Microsoft\Windows\UsrClass.dat“ hat, das war der Fall.

Nachdem ich den Benutzer abgemeldet und neu angemeldet hatte, waren wieder alle Unterschlüssel unter „HKEY_CURRENT_USER\Software\Classes“ vorhanden.

Ich vermute das Problem kam dadurch, dass jemand eine etwas betagte Software als Domänen-Administrator installiert hatte. Ich bin froh, dass es jetzt funktioniert.

Dieser Artikel hat mich auf die richtige Spur geführt, deswegen möchte ich ihn hier auch nochmal erwähnen:
Troubleshooting the Missing Classes Root Key…

In dieser Anleitung möchte ich kurz beschreiben, wie ich auf einem Lenovo S205 (279,00 Euro), welcher mit DOS ausgeliefert wurde, ein Windows 7 Home Premium 32Bit installiert und sämtliche Funktionalitäten (inkl. OneKey Recovery) wie beim gleichen Modell mit Windows 7 (S205 M63D8GE) aktiviert habe.

Die wichtigste Vorbereitung ist bevor man Änderungen vornimmt, die komplette Festplatte mit einem Imaging-Tool (in meinem Fall Acronis TrueImage) zu sichern. Ich empfehle auf ein Netzlaufwerk zu sichern, dann dauert das ganze nicht länger als 10 Minuten. Dieses Image heben wir uns gut auf! Ich habe vom S205 auf ein Samba-Share gesichert und eine Datei mit einer Größe von 3.5GByte erhalten. Wichtig für uns ist später die im Backup enthaltene OneKey Recovery Partition (Partitionstyp 12).

Als Nächstes habe ich ein USB-CD-ROM-Laufwerk angesteckt und per F12-Bootmenü von diesem eine Windows 7 Home Premium Deutsch DVD angebootet. Ich habe das Setup bis zur Auswahl der Partition auf die installiert werden soll durchgeführt und bin dann mit Shift+F10 in eine CMD-Shell gewechselt. Dort habe ich dann das Partitionslayout verändert. (Pech, dass ich mich nicht mehr erinnern kann, deshalb versuche ich hier eine Lösung zu beschreiben die immer funktionieren sollte).

Es sollte klappen, wenn man alle Partitionen löscht und dann die gesamte Festplatte für die Installation von Windows 7 bereitstellt. Dann erst mal Standardsetup von Windows 7 durchführen und die gesamten Treiber und so weiter installieren.

Wenn das System sauber läuft, müssen wir die Partitionierung so verändern, dass das Partitionslayout wie folgt aussieht.

  System-reserviert 100 MB NTFS
  C: 252,91 GB NTFS
  D: 29,00 GB NTFS
  REST FREI

Ich habe also einfach die Systempartition um ca. 45GByte verkleinert und dann dahinter aus diesen 45GByte das Laufwerk D: erzeugt und mit NTFS formatiert. Das Label „LENOVO“ habe ich manuell gesetzt.

Nun müssen wir den restlichen Platz (ca. 16,08 GByte) nocht als OEM-Partition einrichten. Dazu booten wir wieder in unser Disk-Imaging-Tool (z.B. Acronis) und stellen manuell nur die OEM-Partition wieder her und zwar so, dass sie den kompletten Platz von 16,08 GByte also den restlichen freien Festplattenplatz am Ende der Festplatte einnimmt. Das ist mit Acronis Disk Image im manuellen Modus problemlos möglich.

Als Ergebnis sollten wir nun folgendes Partitionslayout erhalten:

Wichtig ist der Type der 16Gbyte Partition, dieser muss als „OEM-Partition = Type 0x12“ angezeigt werden.

Nun machen wir einen Test. Wenn wir das Gerät ausschalten und anstatt dem Einschalter (links) mit einem spitzen Gegenstand den Recovery-Button (rechts) drücken, sollte das Gerät in die Recovery-Partition booten und uns die Möglichkeit für eine Systemwiederherstellung geben. Diese funktioniert jedoch noch nicht, da wir noch keine Systemsicherung durchgeführt haben, also beenden wir das Programm zunächst einmal hier.

Jetzt starten wir wieder Windows und installieren (falls noch nicht geschehen) „Lenovo OneKey Recovery“. Danach erstellen wir mit OneKey Recovery eine Systemsicherung (diese wird dann im versteckten Ordner „D:\Lenovo\OneKey App\OneKey Recovery“ erstellt und steht dann eben auch zur Verfügung, wenn wir in die System-Recovery-Partition booten.

Ich empfehle nun noch unter Windows mit OneKey Recovery 7.0 Wiederherstellungsdiscs zu erstellen. Mit diesen Discs kann man später das System (inklusive aller Partitionen) wieder auf den jetzt erzeugten Zustand zurücksetzen. – Voila!

Was man nicht hinbekommt ist der EFI-Boot und die Systemoptimierung für schnelleres Booten, da Lenovo hierfür ein speziell modifiziertes Windows mit EFI-Boot und ein geändertes BIOS verwendet, aber ganz ehrlich, das kann ich verschmerzen.

Am Wochenende wurde ich durch einen Artikel bei tecchannel.de auf das Programm System Restore Explorer aufmerksam. Mit diesem Tool kann man auf dem System vorhandene System Restore points (diese befinden sich im versteckten Ordner „System Volume Information“) als Ordner im Explorer einhängen und somit auf die zu diesem Zeitpunkt existenten Dateien (wichtige Systemdateien) zugreifen und diese ggf. für eine manuelle Wiederherstellung kopieren.

Das Programm funktioniert leider erst ab Windows Vista, da der Autor ein Problem bei der Funktion SRRemoveRestorePoint unter Windows XP festgestellt hat. Vielleicht schafft hier aber eine zukünftige Version Abhilfe. Zur Not muss man halt manuell Hand anlegen und die Dateien als Systembenutzer aus „System Volume Information“ per Hand kopieren.

Link: System Restore Explorer (Nic’s Blog)

Problem:
Unter Windows kann man neuerdings auch Netzlaufwerke zu WebDAV-Freigaben verbinden. Bei der Verbindung wird man nach dem entsprechenden Passwort gefragt und kann das Passwort auch im Verbindungsdialog zum Abspeichern anhaken. Leider funktioniert das Ganze aber anscheinend nicht und man muss beim Wiederverbinden das Passwort jedes Mal neu eingeben.
Wenn man aber im zentralen Passwortmanager nachsieht, ist das Passwort vorhanden, die Ursache muss also woanders liegen, da das Problem nur auftritt, bei WebDAV-Servern, die sich außerhalb des lokalen Netzwerks, also z.B. im Internet befinden.
Ich habe zunächst ein wenig mit dem Process Monitor mitgesnifft und bin bis zum Dienst „WebClient“ und dem (bei mir nicht vorhandenen Schlüssel „AuthForwardServerList“ gekommen, hab dann aber durch googlen einen Microsoft Artiekl gefunden. Micrsoft KB 943280 You are prompted to enter your credentials when you access a FQDN site from a computer that is running Windows Vista or Windows 7 and has no proxy configured.

Kurz zusammengefasst lautet die Lösung folgendermaßen:

1. Den Registry Editor (regedit) als Administrator starten
2. Folgenden Schlüssel aufrufen „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WebClient\Parameters“
3. Neuen Multi-String-Wert mit dem Namen „AuthForwardServerList“ anlegen.
4. Im neu erstellten Schlüssel können nun die externen Adressen eingetragen werden.

Windows nimmt sobald die URL einen „.“ im Servernamen enthält, dass dieser außerhalb des lokalen Netzwerks liegt und „darf“ nach außen keine Zugangsdaten verschicken. Mit obigem Eintrag funktioniert das Ganze problemlos. Ich rate aber nur „https“-Links einzutragen und keinesfalls Wildcards (*) im Domain-Namen zu verwenden um zu verhindern, dass Passwörter im Klartext ins Internet geschickt werden.

Wer wie ich mit der Windows 8 Developer Preview herumgespielt hat, benötigt ggf. nach einem „Reset your PC“ den Product-Key.
Dieser lautet wie in einem Microsoft Forum bekanntgegeben:

  6RH4V-HNTWC-JQKG8-RFR3R-36498

Vielen Dank an Techdows für diese Information.

Today I tested the Windows 8 Developer Preview and tried the already know „File History“ feature. You need an external drive or a network share to turn on this feature. Since I didn’t have an external drive and no network share available to connect, I just shrinked my C-Drive a little bit, created a new partition with drive letter V:\ and used it’s administrative share for the „File History“. – Worked like a charm. With this trick you can use a local drive for the „File History“ feature.

Just use \\127.0.0.1\[name of administrative share] e.g. \\127.0.0.1\v$ for the network location to add.

Screenshot using File History via local administrative share.

I think this is a nice way to use partitions for the history feature. Of course this makes no sense if you have a hard disk failure and is only recommended for testing purpose.

Today I tested the Windows 8 Developer Preview which is available for public download. The first thing that caught my eyes were the license-terms. As you can see in this picture, people at Microsoft are very humorous! 🙂

Truong Do ist ein Entwickler und arbeitet bei Microsoft. Da er sehr viele Computer (mit Windows) auf seinem Schreibtisch hatte, suchte er eine Möglichkeit, eine Maus für alle Geräte zu verwenden. Außerdem wollte er schnell Dateien zwischen den Geräten kopieren und z.B. auch alle Geräte gleichzeitig sperren.

Er entwickelte deshalb in der „Microsoft Garage“ das Programm „Mouse without Borders„. Die „Microsoft Garage“ ist sowohl eine Abteilung im Microsoft Gebäude, als auch der Name eines Entwicklerprogramms, bei dem Microsoft Mitarbeiter ihre Ideen und Projekte (und wenn sie auch total verrückt sind) in Zusammenarbeit mit anderen Kollegen umzusetzen dürfen. „Mouse without Borders“ ist jetzt als Beta zum Download verfügbar. (Link vom Technet Blog).

Mit dem Programm kann eine Maus gleichzeitig zum Steuern von maximal 4 Windows Computern im gleichen Netzwerk verwendet werden. Ein weiteres Feature ist das
Kopieren von Dateien per Drag&Drop zwischen den Computern.

Einen ähnlichen Ansatz verfolgt auch das Multiplattform-OpenSource-Projekt „Synergy“ und die für nicht-kommerzielle Zwecke kostenlose Software Inputdirector .

Im folgenden Video wird die Funktion von „Mouse Without Borders“ erklärt:

Mouse without Borders Demo Video

Oft ist es notwendig, die kompletten Outlook Kontoeinstellungen zu sichern. Da Outlook seit der Version 2002 die Einstellungen in die Registry schreibt, muss nur (abhängig vom Kontonamen) einer der folgenden Registrierungsschlüssel komplett gesichert werden:

  HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\[Profilname]\9375CFF0413111d3B88A00104B2A6676\

oder

  HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676\

Um die dazugehörigen Dateien muss man sich natürlich manuell kümmern!