Informationswert???
Vielleicht ein wenig, etwa für die Leute ohne DSL.
http://www.heise.de/ct/07/07/148/
Außerdem zur Auswahl des richtigen Notebooks:
http://www.heise.de/ct/07/07/104/
(Sehr allgemein, eher für Anfänger, aber im Heft mit Infos zu Notebooks ohne Spiegeldisplay.)
Tilo Nachdenklich 
Tom West „bzgl Technisat - freu mich für Dich bzgl. Rest: Du hast etwas umschifft, was...“
Hardwareblade kenne ich jetzt, verbindlichsten Dank! - Ansonsten, der PC ist nicht hochgefahren (nicht nur ein Vorfall, sondern mehrfach und reproduzierbar) und ließ sich nicht aktivieren, eben mit der Fehlermeldung "Lizenzstatus konnte nicht ermittelt werden".
Gelöst habe ich das Problem mit Einspielen eines echten Image-Backups (PartitionMagic Kopieren-Funktion) sowie Einspielen eines MBR-Backups, dass ich mit ped.exe erstellt hatte. (Anmerkung: Das klappt nur, wenn eine Festplatte nicht inzwischen zusätzliche defekte Sektoren in diesem Bereich markiert hat. D.h. wenn man Daten von einer angeschlagenen Festplatte retten will ist dieser NTFS-Mechanismus + Aktivierung + Lizenzprüfung fatal.) Macht man beides mit DOS-Disketten, damit Windows erst gar nichts merkt. Schätze das wird ab SATA2 nicht mehr laufen mit diesen alten DOS-Tools.
Das Problem ist, dass Microsoft sich auf den Festplatten-GUID kapriziert, statt auf die Festplatten-ID. Microsoft will - so könnte es scheinen - also NICHT die Hardware identifizieren, sondern wissen, was im MBR passiert, ob wir vielleicht die C-Partition vergrößern usw.. Denn der MBR-GUID wird auch in der Registry mit den Partitionsdaten verrechnet (auch logische Partitionen, UND d.h. ein Backup enthält die MBR-Daten). Wenn MBR und Registry nicht zusammenpassen fährt Windows erst mal nicht hoch. UND die "Hardwareerkennunng" (?) der Aktivierung und Lizenzprüfung scheint sich eben an solchen Unstimmigkeiten auszutoben...bis hin zu den Fragen, die die Hotliner beim Aktivierungsgespräch immer wieder stellen.
http://de.wikipedia.org/wiki/GUID
http://www.heise.de/ct/inhverz/search.shtml?T=Festplatten-ABC&Suchen=suchen&nm=0
Zwei Auszüge aus dem Artikel Festplatten-ABC...mit ganz interessanten Zusatzinfos...etwas Futter für Profis:
"Windows speichert die für die Volume-Zuordnungen relevanten Daten in der Registry unter dem Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. Hier findet man zwei Sorten von Einträgen: In den mit \DosDevices\ beginnenden Registry-Schlüsseln ist hinterlegt, für welche Partitionen die Laufwerksbuchstaben stehen. Zusätzlich tauft Windows jede Partition und jeden Wechseldatenträger mit einem eindeutigen kryptischen Volume-Namen im Format \??\Volume{GUID}. Als "Globally Unique Identifier" (GUID) generiert Windows einen 16 Byte langen hexadezimalen Code. Microsoft verwendet solche IDs an vielen Stellen im System, um Objekte eindeutig zu referenzieren. In der Registry merkt sich Windows dauerhaft die GUID-Namen für alle Volumes, mit denen der PC schon einmal Kontakt hatte.
Auf der Kommandozeile kann man die kryptischen Volume-Namen verwenden, um mit dem Befehl mountvol Laufwerke in einem NTFS-Verzeichnis bereitzustellen - also ohne die Hilfe der Datenträgerverwaltung. Der Aufruf von mountvol ohne Parameter listet alle derzeit angeschlossenen physikalischen Volumes (keine Netzwerk-Laufwerke) mit ihren Langnamen auf. Als Beispiel blendet der Befehl
>mountvol \\?\Volume{085ac6c0-0ede-11d9-befd-806d6172696f}\d:\mount\extern1
eines der gelisteten Laufwerke unter dem Pfad d:\mount\extern1 ein.
Netzwerkfreigaben, die über einen Laufwerksbuchstaben verbunden sind, tauchen nicht unter dem Schlüssel \MountedDevices auf. Deshalb lässt sich Windows XP leicht verwirren und kommt bei der Zuweisung neuer Geräte ins Stolpern, wenn der nächste vermeintlich freie Buchstabe bereits von einer Freigabe belegt ist. Das Netzlaufwerk verdeckt dann etwa den eingestöpselten USB-Stick, der so lange unsichtbar bleibt, bis man ihm in der Datenträgerverwaltung einen anderen Buchstaben zuweist."
"Die Registry-Werte, die Windows für die GUID-Namen und Laufwerksbuchstaben hinterlegt, sind binär und sie unterscheiden sich je nach Typ des referenzierten Volumes. Für Partitionen auf Basisdatenträgern (so bezeichnet Microsoft normale Festplatten, die mit einer klassischen Partitionstabelle versehen sind [1]) ist der Binärwert 12 Bytes lang. Interessant sind hier die ersten vier Bytes: Sie enthalten die Signatur der referenzierten Festplatte, die Windows bei der Initialisierung einer fabrikneuen Platte im Master Boot Record hinterlegt. Die restlichen Bytes kennzeichnen die Position der Partition auf dieser Festplatte. Die Registry-Werte verknüpfen Laufwerksbuchstaben und die GUID-Namen also mit einer bestimmten Platte - unabhängig davon, mit welchem IDE-Anschluss sie gerade verbunden ist.
Die Signatur einer Platte kann der Kommandozeilenbefehl diskpart ermitteln, der selbstverständlich Administratorrechte voraussetzt: Dieses Werkzeug zeigt nach dem Start eine eigene Eingabeaufforderung, die spezielle Befehle verarbeitet. Für Windows 2000 bietet Microsoft diskpart als separates Werkzeug zum Download an (siehe Soft-Link).
Mit select disk 0 wählen Sie die erste Festplatte als Ziel für weitere Kommandos aus. Anschließend zeigt detail disk eine Übersicht der auf der Platte enthaltenen Volumes und die ihr zugewiesenen Laufwerksbuchstaben. Unter "Datenträgerkennung" findet man die 4 Byte lange Festplattensignatur, auf die sich die Registry-Einträge beziehen.
Windows XP und 2000 verknüpfen ihre Laufwerksbuchstaben mit einer Signatur, die im Master Boot Record der Festplatte eingetragen ist.
Allerdings sind die Signatur-Bytes in der Registry in umgekehrter Reihenfolge hinterlegt: Zeigt diskpart etwa die Plattensignatur BFEBBFEB an, findet man in den Registry-Einträgen der zugehörigen Volumes die Bytefolge "eb bf eb bf". In letzterer Form ist die Signatur auch im MBR gespeichert; mit einem Diskeditor findet man die vier Bytes an der Position 0x01B8."
Wenn Microsoft also - was offenkundig der Fall ist - die Aktivierung an den Festplatten-GUID knüpft, dann hat man nach Low Level Format oder fdisk /mbr Aktivierungspunkte gesammelt. Bei WinVista 11 Punkte von 25. Momentan ist das Uralt DOS-Progrämmchen ped.exe (passt noch auf die recht volle Win98-Diskette) ein gewisser Rettungsanker, aber mit dem Umstieg auf SATA2 (nicht mehr befehlskompatibel zu PATA) dürfte das Verfahren gestorben sein. Die Weiterentwicklung von NTFS liegt nicht bei Microsoft, sondern bei Veritas und damit beim giftenden Microsoft-Konkurenten Symantec (Sicherheitsoftware). Ich glaube da braut sich was zusammen, denn die ganze Festplatten-GUID-Geschichte lässt sich nicht aus der Welt schaffen, aber die Aktivierung fußt darauf. Und Symantec hat schon gemäkelt, Microsoft hätte zuviele NTFS-Geheimnisse verraten.
