Hallo,

ich würde es gerne entfernen, aber wie. Wenn ich die Berechtigungen einsehen möchte, kommt Freigabe ist für admin. Zwecke eingerichtet. bei C: und E:
Es ist auch immer alls doppelt. Ich kann in E: einen neuen Orner anlegen und er ist in C: vorhanden. Lösche ich diesen von C: ist er auch in E: weg.
 
Ich gebe, vorerst, auf.

Sieh es sportlich. ;)

koloth schrieb:
Edit-2, diesmal aber eher ot
ot:
Tue es als Schönheitsfehler ab. Es funktioniert ja.
Alle Buchstaben wirst Du, zumal bei einem Läppi, eh nicht brauchen.
Raid-1 mit nur einer Partition hat auch nicht jeder. :D

:D
 
Lies mal in der XP-Hilfe über "Bereitstellen eines Laufwerkes" nach und untersuche danach C:,
ob du nicht in irgend einem Ordner C als E bereitgestellt hast.
 
Hallo,

dann sollte ich es mit Diskpartsehen. Es ist kein Laufwerk bereitgestellt.
 

Anhänge

  • Diskpart.JPG
    Diskpart.JPG
    45,1 KB · Aufrufe: 533
Ich habs geschafft.

Die identischen ID FP C: & E: habe ich nochmals getauscht und neu gestartet. FP E: war sofort verschwunden.

Danke an alle die Helfer!

PS: Ich weiß nicht warum ich das getan habe, aber es hat funktioniert.
 
Kopieren der Systemfestplatte in Windows 2000 und XP

Es geht auch einfacher (Auszug aus Manual von Paragon Partition Manager):

*** ZITAT***
3.2.4.1 Kopieren der Systemfestplatte in Windows 2000 und XP
Der Partition Manager wird ab und zu zum Klonen oder Verteilen von Systemfestplatten benutzt. Falls diese Aktion für Windows 2000/XP Systemfestplatten ausgeführt wird, muss die folgende Prozedur durchgeführt werden, um Probleme beim Kopieren der Festplatte zu vermeiden:
  1. Verbinden sie Quell- und Zielfestplatten mit dem Computer. Starten Sie den Computer und starten sie den Partition Manager (jede Version, für jede Plattform).
  2. Unter Verwendung des Partition Manager klonen Sie die Quellfestplatte zur Zielfestplatte.
  3. (!) Fahren Sie den Computer herunter.
  4. (!) Entfernen Sie die (physische) Verbindung der Quellfestplatte.
  5. (!) Starten Sie den Computer von der Zielfestplatte. Während des Startvorgangs sollten keine Probleme auftauchen.

Nach Beendigung dieser Prozedur können Sie beide Festplatte ohne Probleme unabhängig voneinander oder zusammen auf dem gleichen Computer verwenden.

Das Problem ist, dass Windows 2000 und XP Informationen über alle gemounteten und nicht gemounteten Partitionen, die jemals mit den Festplatten des Systems verbunden waren, in einer speziellen Datenbank speichert. Partitionen werden durch die Festplatten-Seriennummer und die relative Ordnung der Partitionen identifiziert. Diese Datenbank wird regelmäßig auf den neusten Stand gebracht. Während des Klonens von Festplatten, wird diese Datenbank auf der Zielfestplatte dupliziert.
Normalerweise führen die Anwender die letzten zwei Schritte nicht aus, d.h. sie lassen die Quellfestplatte während des ersten Neustarts von der Zielfestplatte, mit dem Computer verbunden. Beim Start findet Windows die alte Festplatte, verwendet wieder die Laufwerksbuchstaben der alten Partitionen in den alten Daten, fügt neue Laufwerksbuchstaben für die Partitionen auf der Zielfestplatte hinzu und aktualisiert die Datenbank.
Wenn die Verbindung zur Quellfestplatte dann unterbrochen wird, wird die einzelne Zielfestplatte unbrauchbar: Windows kann nicht von dieser Festplatte starten, da einige wichtige Systemdaten mit nicht vorhandenen Laufwerken verbunden sind.

*** ENDE ZITAT ***
 
Hallo!

Suche jetzt auch schon eine Weile im Internet, wie ich am geschicktesten Windows auf ne neue Platte ziehe. Habe diese Anleitung hier gelesen und kam dann auf eine eigene Idee, die ihr mir hoffentlich absegnen könnt.

Also auch mein Problem ist: Ich will Win XP auf eine neue größere Platte Ziehen. Bzw auf eine gleichgroße Partition einer größeren Platte.

Meine Idee: ich bau die alte Platte aus und die neue ein, starte von der windows CD und installiere windows einfach komplett neu auf die neue Platte.

Jetzt pack ich mir beide PLatten und schließe sie an einen anderen Rechner als Zweit- und Drittplatte an. Dort kopier ich einfach alles von der Systempartition der alten platte auf die neue. Geht das??

Und würde es auch klappen, ohne windows zuerst auf der neuen zu installieren?

Hoffe, ihr könnt mir helfen!
 
Hallo und willkommen :)
Das mit der Installation kannst Du Dir sparen - einfach die Partition klonen und falls es mit dem Booten nicht klappt, mit der XP-CD starten, die Reparaturkonsole aufrufen und /fixboot sowie /fixmbr ausführen, dann sollte das behoben sein.
 
Windows System Partition kopieren

Da jibet einen alten DOS Befehl, der früher XCOPY32 hieß.
Unter XP nur noch XCOPY

Im Explorer Extras, Datei ansicht "Alle Dateien und Ordner anzeigen" aktivieren.

Dann DOS Fenster öffnen und vorher alle Virenprogramme oder sonstigen
Überwacher von Dateien oder Laufwerken, auch Backupprogramme, schließen.
Evtl. im TASK Manager in den Diensten alle beenden was dazugehören könnte.

Dann im DOSfenster folgenden Command eintippen:

xcopy c:\*.* [ziellaufwerk]:\ /h/c/e/k/y/r/o und ENTER

Vorraussetzung ist, dass die Platte schon partitioniert ist und formatiert mit dem Dateisystem wie das Original.

Danach Or Plate rausbauen, Zielplatte umjumpern auf Master und System starten. Wenn sie nicht bootet, mit WinXP CD auf reparieren und Masterboot record neu schreiben wie vom Kollegen beschrieben.
 
Es geht auch einfacher (Auszug aus Manual von Paragon Partition Manager):

*** ZITAT***
3.2.4.1 Kopieren der Systemfestplatte in Windows 2000 und XP


Normalerweise führen die Anwender die letzten zwei Schritte nicht aus, d.h. sie lassen die Quellfestplatte während des ersten Neustarts von der Zielfestplatte, mit dem Computer verbunden. Beim Start findet Windows die alte Festplatte, verwendet wieder die Laufwerksbuchstaben der alten Partitionen in den alten Daten, fügt neue Laufwerksbuchstaben für die Partitionen auf der Zielfestplatte hinzu und aktualisiert die Datenbank.
Wenn die Verbindung zur Quellfestplatte dann unterbrochen wird, wird die einzelne Zielfestplatte unbrauchbar: Windows kann nicht von dieser Festplatte starten, da einige wichtige Systemdaten mit nicht vorhandenen Laufwerken verbunden sind.

*** ENDE ZITAT ***

Verstehe das nicht ganz.Über kurze Klärung würde ich mich freuen.

Also...Ich habe die bisherige Systempartition auf das gewünschte Laufwerk kopiert.
Starten kann ich dieses. Einige Prozesse laufen immernoch über die alte Platte, obwohl ich die Alte sogar im Bios deaktiviert habe..

Habe dann wie beschrieben die IDs geändert aber jetz weiß ich nicht, ob ich herunterfahren soll und die alte Platte rausnehmen soll oder nicht.

Oder mit alter Platte neustarten, dann herunterfahren und dann rausnehmen.
 
NT-basierte Systeme arbeiten intern nicht mit Laufwerksbuchstaben sondern mit IDs. Ähnlich Linux mit den Mountpoints.
XP bezieht nun zusätzlich die Festplatte in diese ID auf irgendeine Weise mit ein.
Nicht ganz: Laufwerke/Partitionen sind zunächst nur kaltes Material. Erst wenn das Betriebssystem die Laufwerke dem Anwender zum Zugriff zur Verfügung stellt ('einhängt' - mountet), sind sie präsent. Bei Windows erfolgt dieses Mounten automatisch für alle erkannten Laufwerke/Partitionen, die Mount-Points sind die zugewiesenen Laufwerksbuchstaben. Bei Linux wird im Regelfall nur die Haupt-Festplattenpartition automatisch gemountet, alle weiteren Festplatten-Partitionen aber nur per Anweisung in der Betriebssystem-Tabelle /etc/fstab mit Angabe, auf welchen /media-Verzeichnisnamen gemountet wird (also vergleichbar dem Windows-SUBST-Befehl) sowie ob Lese- und/oder Schreibberechtigung für Normalanwender erlaubt sind. CD-DVD-Geräte sowie USB-Laufwerke dagegen werden auch bei Linux automatisch gemountet.

Neben dem Ordnungsprinzip "Erste Festplatte [Primäre, dann in Reihenfolge die logischen Partitionen], zweite Festplatte [Primäre..].. CD-DVD-Geräte, USB-Platten.." gibt es (im Linux-Sprachgebrauch) noch die UUID - den elektronischen Fingerabdruck des Datenträgers: Damit ist XP in der Lage, einer einmal eingestöpselten USB-Platte beim nächsten Einstöpseln wieder den gleichen Laufwerksbuchstaben zuzuweisen. Praktischer Nutzen in meinem Fall: Auf dem PC laufen neben Linux noch vista und XP, die zugewiesenen Laufwerksbuchstaben der USB-Platten wichen jedoch bisher ab. Durch Austausch/Anpassung der UUIDs in der Registry kann nun die Laufwerkszuordnung gleich gemacht werden.

Das Ordnungsprinzip "Erste Festplatte [Primäre, dann in Reihenfolge die logischen Partitionen], zweite Festplatte.." ist aber nicht zwingend. Bei der Windows-Live-CD BartPE werden zum Beispiel erst allen primären Laufwerken/Partitionen die Laufwerksbuchstaben zugewiesen, dann den logischen Laufwerken... Nach dem gleichen Prinzip geht Linux vor, nur dass die Laufwerkskennung (das Device) nicht nur aus einem Buchstaben besteht, sondern aus dem Device-Namen und zusätzlich fortlaufenden Nummern (sda1=Primäre Partition der ersten Festplatte..sda99 , sdb1=Primäre Partition der zweiten Festplatte..). Damit ist Linux nicht nur eindeutiger als der eher zufällige Buchstabensalat unter Microsoft, sondern auch zukunftssicher: Da das deutsche Alphabet nur aus 27 Buchstaben besteht, dürften die kleinen Männchen in den Windows-Betriebssystemen beim Einstecken eines vollbestückten USB-32fach-Kartenlesers in arge Verwirrung geraten.
----------------------
Das also zur Ergänzung der dankenswerten Anleitung von koloth. In den Beiträgen wurde jedoch folgender Fall noch nicht angesprochen, nämlich dass die erste Festplatte sich ohne Vorwarnung verabschiedet -zum Beispiel nach einem Mainboard-Kurzschluss- und somit alle Sicherungen per Images, xcopy /kreisch, WinRAR von einer Live-CD aus auf eine NEU EINGEBAUTE (und nicht baugleiche) Festplatte ... unbrauchbar sind, da die Betriebssystem-UUID der neuen Festplatte mit Bestimmtheit von der UUID der gesicherten alten Festplatte abweicht - oder habe ich etwas übersehen in den Beiträgen?
---------------
EILE MIT WEILE - ich habe dafür einen soliden Lösungsvorschlag - aber das Bessere ist der Feind des Guten - also warte ich mal ein bischen, ob nicht noch was Besseres kommt :)
 
EILE MIT WEILE - ich habe dafür einen soliden Lösungsvorschlag - aber das Bessere ist der Feind des Guten - also warte ich mal ein bischen, ob nicht noch was Besseres kommt :)

Nur zu.
Verbessern kann man etwas nur dann , wenn man die Vorlage schon kennt.
Insofern lasse ich mich auch gerne verbessern.


Der Vergleich mit den Mountpoints war eigentlich nur als "sprechendes Beispiel" gedacht.
99,99% der User hätte das auch gereicht.

Siehe Anzahl der Views. :D
 
Hi koloth,
meine Anmerkung ".. also warte ich mal ein bischen, ob nicht noch was Besseres kommt" bezog sich NICHT auf deinen Lösungsweg, im Gegenteil:

Auf deinen Beitrag bin ich gestoßen, weil ein MS-Nutzer mich um Hilfe bat: Die erste Festplatte war verreckt, und die sonst so zuverlässige dateibezogene Datensicherung (mehrfach im Laufe der Zeit erfolgreich restauriert wegen vermatschtem XP) versagte beim Restore auf die neue Festplatte - Ergebnis BlueScreen. Und der hier genannte Lösungsweg funktioniert ja nur, wenn die alte Festplatte noch ansprechbar ist. Letztlich hat er XP neu aufgebaut und alle Anwendungen neu installiert sowie eingerichtet, was ihn weit über einen Tag gekostet hat.

Danach hatte ich ein bischen getestet, wie man aus der restaurierten Datensicherung die UUIDs der Festplatten/Partitionen ändern oder entfernen kann (\DosDevices\C: usw.), doch alle Versuche waren negativ
-Nach Bearbeiten der ..\Windows\System32\Config\System mit einem Hexmonitor meldet sich beim nächsten XP-Start 'LSASS - das Kennwort ist nicht gültig" oder so ähnlich - und anschließend automatisches Rebooten.
-Werden per Windows-Live-CD die Registry-Datenbankteile ..System und ..Software von einer ähnlichen XP-Installation (meine Produktions-Partition) der gleichen Festplatte auf die simulierte defekte XP-Partition (Test-Partition) einfach rüberkopiert, so führt Rebooten zu einem sofortigen BlueScreen.

Inzwischen habe ich eine ziemlich einfache Lösung des UUID-Problems gefunden, die mit letzter Sicherheit aber nur bei dateibezogenen Datensicherungen funktioniert und möglicherweise NICHT bei den so beliebten Image-Sicherungen - deshalb meine Anmerkung, ob nicht noch was Besseres an Vorschlägen kommt - also noch etwas warten.

Bei den Windows-Image-Sicherungen bin ich ohnehin skeptisch, es gibt genug Berichte über das Versagen von Ghost, DriveImage, Paragon (nicht nur wegen UUID)... Deswegen werde ich im Laufe des September in einem eigenen Betrag eine dateibezogene solide Datensicherungslösung per Live-CD vorstellen, die lizenzrechtlich unproblematisch ist. Und man kommt sogar problemlos an Einzeldateien, gelegentlich hole ich mir noch alte Tools aus meinem Archiv der Win98-Installation, obwohl Win98 seit vier Jahren nicht mehr auf meinem PC installiert ist, aber ich könnte.. :)

Also nichts für ungut.
 
Also - hier ist er, der erweiterte Lösungvorschlag.

Kurze Zusammenfassung des bisherigen Toppics
In seinem Eingangsbeitrag hat koloth prägnant das Geheimnis gelüftet, warum eine XP-Datensicherung nicht einfach auf eine neue Festplatte restauriert werden kann - weil nämlich der Neustart der neuen Festplatte(n-Partition) zu einem BlueScreen führen würde, da XP beim Booten 'elektronische Fingerabdrücke' (UUIDs) der Festplatten benutzt. Da durch das Restaurieren die UUIDs der alten Festplatte rückgesichert wurden, wird das neue Laufwerk schlicht und einfach nicht erkannt.

Sodann wird anschaulich mit Bildschirmabdruck dargestellt, wie durch Anschluss des alten und des neuen Laufwerks sowie Übertragen der UUIDs letztendlich "auf das neue Laufwerk bootfähig umgezogen werden kann". Die hohen Zugriffszahlen bezeugen, dass diese Lösung ein richtiger Weg ist.
-----
Offen blieb noch die Frage, wie zu verfahren ist, wenn altes und neuen Laufwerk nicht gleichzeitig angeschlossen werden können, weil das alte Laufwerk zum Beispiel defekt ist oder beim Notebook kein Platz für ein zweites Laufwerk vorhanden ist. Das Hauptproblem besteht darin, dass die alten und somit für das neue Laufwerk falschen UUIDs in der Datensicherung in einer Systemdatenbank enthalten sind, die wiederum nur mit gestartetem XP veränderbar sind - jede Art Patchversuch wurde durch die XP-Sicherungsfunktionen erkannt und machte die restaurierte Datensicherung unbrauchbar - siehe vorgehender Beitrag.

1. KEINE BANGE vor der folgenden Textmenge, es gibt am Ende des Beitrags die Kurzfassung der Lösung; die Detailbeschreibung bis zum gefundenen und überprüften Lösungsweg dürfte aber Zweifler überzeugen. Alle Tests wurden mit XP-SP3 durchgeführt.

Die nächste Überlegung brachte mich dann auf den Lösungsweg: Wenn XP neu auf einem Laufwerk installiert wird, sind ja noch keine UUIDs gespeichert, XP muss sich also OHNE UUIDs ausschließlich an den Partitionen orientieren können. Zum Testen ob das funktioniert, wurde in der entsprechenden Systemdatenbank per REGEDIT der Ordner HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices in ..\MountedDevice2 umbenannt.
[Ein evtl. Ordner ..\MountedDevice1 kann entfernt werden oder auch stehenbleiben, er hat keine Funktion und könnte ein Installationsrest sein, unter vista gibt es diesen Ordner in der Registry auch nicht; die unter vista in der Registry gespeicherten UUIDs sind aber mit den XP-UUIDs identisch.]

2. Danach wurde das System heruntergefahren und mit der BartPE-Windows-Live-CD eine dateibezogene Vollsicherung per WinRAR durchgeführt sowie anschließend in ein beliebiges Verzeichnis einer USB-Platte restauriert. Dann in das Verzeichnis ..\Windows\System32\Config gewechselt und die Datei SYSTEM in SYSTEM.txt umbenannt - und nun kann die Verifikation gestartet werden: Der Registry-Ordner ..\MountedDevices wurde ja UMBENANNT/nicht gelöscht [in Datenbanken wird nicht gelöscht, sondern werden Einträge nur deaktiviert] - und es soll ja Monitor-mäßig erstmal geprüft werden, ob wirklich kein Eintrag ..\MountedDevices mehr vorhanden ist, bevor die Datensicherung zurückgeschrieben wird. Also '..\SYSTEM.txt' mit WORDPAD öffen und Datei - SUCHEN - und tatsächlich gibt es nur einen Eintrag MountedDevice2, aber nicht MountedDevices .

3. Der Rest war einfach: Die dateibezogene Vollsicherung wurde (weiter von der LIVE-CD aus) nach C: zurückgeschrieben und neu von Laufwerk C: gebootet - und das restaurierte XP auf C: bootet einwandfrei OHNE UUIDs bis zum Desktop durch! Keinen Schreck bekommen, wenn ich jetzt ergänze "fast einwandfrei", denn nachdem der Desktop praktisch aufgebaut war, machte XP fast eine halbe Minute lang den Eindruck, es sei eingefroren - anschließend war alles normal, auch bei allen späteren Neustarts. Das kurzfristige Einfrieren war auch bei zwei Restore-Nachtests zu bemerken, es könnte daher vermutet werden, dass XP wegen der fehlenden UUIDs eine "Sicherheits-Sonderprüfung" durchführt und dann anschließend die UUIDs neu generiert. Um sicher zu sein, dass XP die UUIDs nicht aus irgendeiner Sicherungsdatei zurückholt, habe ich vor dem Reboot zwei USB-Laufwerke abgestöpselt - und siehe da, in der neu erstellten ..\MountedDevices waren deren Einträge NICHT enthalten, wohl aber in der umbenannten ..\MountedDevice2
-Nach Wiedereinstöpseln der USB-Laufwerke waren deren Laufwerksbuchstaben vertauscht (was sich über Tausch der Registry-Einträge oder Zurück-Umbenennen des Registry-Ordners ..\MountedDevices und Reboot leicht beheben lässt), also ein weiterer Hinweis, dass XP in der Lage ist, neue Laufwerke (zunächst) OHNE UUID einzubinden.

4. Eine XP-Systemrestaurierung funktioniert also demnach auch ohne UUIDs, hier am erfolgreichen Beispiel der dateibezogenen Datensicherungsmethode. Bei Imagesicherungen ist dieser Lösungsweg aber noch fraglich. Zu Testzwecken wurde wiederum auf Laufwerk C_XP in der Registry ..\MountedDevices in ..\MountedDevice99 umbenannt, DriveImage2002 von C: angestartet, Systemabschluss *). Die DriveImage-Sicherung wird jetzt VOR DEM folgenden Booten von XP_C: erstellt, dann auf eine LEERE Festplatten-Partition restauriert und wie in Ziffer 2 beschrieben in der Datei "..\SYSTEM.txt" nach einem Eintrag 'MountedDevices' gesucht - keinen gefunden/also alles wie gewünscht OHNE UUID. Somit ist die Lösung 'Registry-Umbennen MountedDevices' VOR STARTEN DER DATENSICHERUNG auch für DriveImage2002 tauglich. Da andere Image-Sicherungslösungen vermutlich wie DriveImage2002 ebenfalls mit einem eigenen Betriebssystem oder zu einem frühen Zeitpunkt nach dem XP-Booten greifen, liegt die Vermutung nahe, dass die Lösung auch für andere Image-Anwendungen tauglich ist - Klarheit kann aber nur der Test analog dem beschriebenen Vorgehen wie mit DriveImage2002 bringen. Falls ein zweites XP auf dem PC vorhanden ist, so sollte [nach Umbenennen von ..\MountedDevices auf dem zu sichernden XP_C] von diesem zweiten XP aus die Imagesicherung gestartet werden - die Datensicherung ist dann voll tauglich für den Umzug auf eine neue Festplatte.

*) GENAUER: Meldung 'Preparing your PC to reboot and run DriveImage' - reboot - CalderaDOS starting from Floppy Image. Das für XP_C gebildete Image wurde nach Festplatten_E: geschrieben und von E: wieder nach C: restauriert. Der Eintrag ..\MountedDevice99 ist vorhanden, also ist ..\MountedDevices mit den UUIDs neu gebildet worden, ersichtlich auch daran, dass die zwei UUIDs der VOR Starten von DriveImage2002 abgeschalteten USB-Laufwerke in ..\MountedDevice99 enthalten sind, in ..\MountedDevices aber nicht.
==================================
Erfahrungs-Rückäußerungen zu anderen Imagelösungen sind ausdrücklich erwünscht - wenn MS die Nutzer in solchen Fragen allein lässt, dann müssen wir uns eben selbst helfen.
==================================
[5. Dateibezogene XP-Datensicherungen haben den Vorteil, dass durch Entpacken in ein alternatives Laufwerk/Verzeichnis auf Einzeldateien zugriffen werden kann. Sie sind aber deutliche langsamer als Image-Sicherungen, und beim (eher seltenen) Umzug von XP auf eine neue Festplatte fällt gegenüber Image-Lösungen Mehrarbeit an, weil nämlich vor dem Restaurieren der Datensicherung erstmal ein Simpel-XP installiert werden muss, damit der Bootsatz u.ä. erstellt wird. Dennoch hält sich der Gesamt-Zeitaufwand mit zwei Stunden in Grenzen, ist jedenfalls zielsicher und wesentlich einfacher als eine komplette Neuinstallation. Außerdem muss man ja nicht zusehen, wenn der Rechner arbeitet :)]

Kurze Zusammenfassung der ergänzenden Lösung
Die ergänzende Lösung ist an sich banal, es war nur etwas Tüftelei erforderlich, mit welchen Tests ermittelt werden kann, dass die Datensicherung tatsächlich NICHT die untauglichen 'elektronischen Fingerabdrücke' (UUIDs) der alten Festplatten enthält: VOR JEDER Vollsicherung wird nach Start des zu sichernden XP-Systemlaufwerks (meist C) REGEDIT aufgerufen und der Ordner HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices in ..\MountedDevice2 oder ähnlich umbenannt werden. Damit wird die anschließend durchgeführte Datensicherung für die Wiederherstellung auf einer neuen Festplatte tauglich, sowohl für Sicherungen von einer Windows-Live-CD aus als auch für Imagesicherungen von einer ZWEITEN XP-Partition aus auf dem gleichen PC. Die von koloth eingangs dieser Anleitung beschriebene Lösung bleibt weiterhin maßgeblich, wenn altes und neues Laufwerk gleichzeitig im Zugriff sind, was im Falle eines Plattencrashs der alten Festplatte oder bei fehlender Einbaumöglichkeit in Notebooks nicht der Fall ist, aber jeder Nutzer kann sich ja frei entscheiden oder auch beide Lösungswege praktizieren. Den von mir privat betreuten XP-Normalanwendern empfehle ich im ersten Monat die UmzugsTaugliche Datensicherung [also mit UT kennzeichnen], danach zwei Monate die übliche Datensicherung ohne Registry-Eingriff usw. im Wechsel.
Für Auch-LINUX-Nutzer: Das vorherige Umbenennen des Registry-Ordners ..\MountedDevices muss natürlich auch durchgeführt werden, wenn XP von Linux aus gesichert wird, damit die XP-Sicherung UmzugsTauglich ist.

Ist auf dem PC nur EIN startbares XP vorhanden und wird eine andere Imagelösung als DriveImage2002 durchgeführt, so muss -wie in Ziffern 4 und 2 beschrieben- getestet werden, dass diese Imagesicherung keine RegistrySpeicherung ..\MountedDevices enthält, sonst wäre diese Sicherung nicht umzugstauglich: Der beschriebene (nur einmalig durchzuführende) Testweg verschafft Klarheit dazu.

Disclaimer: Alle Tests wurden sorgfältigst und mehrmals durchgeführt (einschließlich mehrerer Datenwiederherstellungen wegen BlueScreens nach untauglichen Lösungsversuchen). Dennoch kann keine irgendwie geartete Verantwortung oder Haftung übernommen werden, dazu sind die PC-Konfigurationen auch teilweise zu komplex (DUAL-Boot und ähnliches).
-------------
vista - NEIN!
1. vista ist in vielem anders als seine Vorgänger. Unter anderem weicht nach meinen Tests das vista-NTFS erheblich von XP-NTFS ab. Beispielsweise führte der Versuch, mit einer XP-Live-CD vista zu sichern und zu restaurieren dazu, das vista zwar funktionsfähig mit allen Anwendungen wiederhergestellt werden konnte, aber praktisch alle eigenen als auch Systemlinks 'verschwunden' waren, also unbrauchbar. Es ist also auch Vorsicht angesagt, wenn systemnahe Dateien zwischen XP und vista ausgetauscht werden, denn da spielt das Rechtemanagement mit Sicherheit eine dominante Rolle.
Als einzige dateibezogene vista-Datensicherung ist mir bisher die Lösung mit Knoppix-Linux-DVD ab Version 5.20 bekannt - die mit dem ntfs-3g-Treiber.
2. Wird testweise in der vista-Registry ..\MountedDevices umbenannt und danach vista rebootet, erscheinen zuerst diverse Fehlermeldungen und anschließend wegen 'nicht gefundener Profile' ein Minimal-Hilfsuser. Selbst grundlegende Systemfunktionen fehlen. Der Rückweg erforderte aber kein Restaurieren, sondern ging mit Klick auf das Windows-Symbol links unten - Suchen nach cmd.exe - draufklicken - Registry - und wieder ..\MountedDevice2 auf ..\MountedDevices umbenennen: Beim vista-Neustart war alles wieder heile.
3. Beim Versagen der ..\MountedDevices-Umbenennenlösung bei vista könnte es allerdings eine Rolle spielen, dass vista bei mir auf "F:" installiert ist (sagt XP), sich nach dem Booten aber als C: mountet. Eventuell hat jemand/jefrau die Gelegenheit, beim vista-Umzug auf eine andere Festplatte den von koloth beschriebenen Lösungsweg mit alter UND neuer Festplatte auszutesten.
 
FAZIT 1:
Sowohl XP_C als XP_E sind nach nach meinen Tests mit der Registry-Umbennen-Lösung sofort voll umzugstauglich.

FAZIT 2:
Ein auf der Primären Partition installiertes vista ist ebenfalls mit der Registry-Umbennen-Lösung sofort voll umzugstauglich, siehe auch Details unter FAZIT 3. Der von koloth beschriebene Lösungsweg (alte und neue Festplatte angeschlossen) ist VOLL vista-tauglich, sowohl für vista auf der Primären als auch auf anderen Partitionen:

Beim festgestellten Misserfolg des simulierten Restaurierens (Basis: Sicherung nach Registry-Umbennen-Lösung) von vista auf einer Erweiterten Partition hat vista seinen Ablauf enthüllt: Es startet zunächst (hat sich also am restaurierten Bootmanager orientiert), hat dann aber im weiteren Ablauf auf die Partition mit der vista-UUID aus der Registry zugegriffen.
a) Bei der "koloth-Lösung" ist diese (alte) Festplatte ja noch da, also ok.
b)Bei der Registry-Umbennen-Lösung werden die UUIDs von vista neu erstellt. Da vista nach Restaurieren aber mit einem Hilfs-User und abgemagerten Systemfunktionen endete, muss beim UUID-Generieren und Einstellen in die Registry-\DosDevices\ etwas schiefgelaufen sein. Im Nachfolgenden werden die Ursachen dafür aufgespürt und die relativ einfache Lösung vorgestellt.

CH-Jan schrieb:
Beim Versagen der ..\MountedDevices-Umbenennenlösung bei vista könnte es allerdings eine Rolle spielen, dass vista bei mir auf "F:" installiert ist (sagt XP), sich nach dem Booten aber als C: mountet.
Mann oh Mann, mein Spürsinn lässt zu wünschen übrig, dabei liegen die Indizien dazu durch das Umbennen doch direkt vor meiner Nase :(

Naja, als "Abfallprodukt" hat sich nun herausgestellt, wie die von mir beschriebene Lösung auch dann für vista funktioniert, wenn vista nicht auf der Primären Partition installiert wurde, und der "koloth-Lösungsweg" für alle Partitionsvarianten funktioniert. Aber nun mal Schritt für Schritt - zuerst die "Sicht" auf die Festplatten-Partitionen (mein komplexerer "Fall"):

Physikalische Plattenpartitionen Sicht XP Sicht vista Verwendungszweck
"Partition 1"(Primäre Partition) = C: = D: WindowsXP_C
"Partition 2"(Erw. Partition 1) = D: = E: Swap-Partition
"Partition 3"(Erw. Partition 2) = E: = F: WindowsXP_E
"Partition 4"(Erw. Partition 3) = F: = C: Windows-vista

Nach Umbennen von ..\MountedDevices in ..\MountedDevice-- und vista-Reboot hat vista ..\MountedDevices wiederhergestellt, aber mit der 'fixen' Festlegung, dass auf 'Partition 1' vista installiert sein muss, was ja in meinem Fall nicht zutrifft - vista liegt (auch für vista erkennbar) auf Partition 4 - wieder mal ein grober MS-Schnitzer: Vista ist zwar per Bootmanager definitiv von Partition 4 gestartet, hat aber versucht, Profiles usw. von der Primären Partition (XP_C) nachzuladen, wie im vorigen Beitrag beschrieben: Dies belegen eindeutig die beigefügten Registry-Hardcopies [vista-UUIDs.jpg - Verschiebung der UUIDs bei den DosDevices-Einträgen!]

FAZIT 3:
Auch für den Fall "vista nicht auf der Primären Partition installiert" gibt es eine Lösung - wir müssen nur das "Bäumchen-wechsel-dich-Spiel" 'im Auftrag von von vista' händisch nachholen.
a) Als Anlage sind zwei Registry-Hardcopies beigefügt [vista-UUIDs.jpg]
MountedDevice-- zeigt die UUIDs, die vista wegen fehlender UUIDs im Registry-Ordner ..\MountedDevices NEU aber in fehlerhafter Reihenfolge rekonstruiert hat [aber korrekt aus XP-Sicht in lfd. Folge der Partitionen]
MountedDevices zeigt die UUIDs der vista-Originalinstallation, also die Reihenfolge, wie die UUIDs aus vista-Sicht den \DosDevices\ hätten zugeordnet werden müssen [vista-Partition wird als "C:" simuliert], damit vista vollständig aufgebaut wird!
b) Der Vergleich der beiden Registry-Hardcopies zeigt sehr schön dieses "Bäumchen-wechsel-dich-Spiel" der UUIDs-\DosDevices
c)Die Lösung gestrafft als Aktionsplan - die vorgehenden Erläuteren dienten nur dem besseren Verständnis

Eine UmzugsTauglich gemachte Datensicherung mit vista auf F: (Partition 4) wird auf einer neuen Festplatte nach Partition 4 (wie auf der "Alt-Festplatte) restauriert; vista startet zwar, aber mit vielen Fehlermeldungen und einem Minimal-User. Anschließend wird auf das Windows-Symbol links unten geklickt - Suchen nach cmd.exe - draufklicken - Registry - HKEY_LOCAL_MACHINE - SYSTEM - MountedDevices
Nochmal zur Erinnerung: Beim vista-Reboot von der neuen Festplatte wurden die korrekten neuen UUIDs (elektronischen Fingerabdrücke) der Partitionen/Laufwerke gebildet, aber in der aus vista-Sicht falschen Reihenfolge, also müssen wir vista "helfen". Um nun nicht eine fehlerträchtige Hexcodes-Umkopier-Arie starten zu müssen, hier kommentarlos und vollständig (für meinen Fall) fünf "simple" Registry-Umbennungen in Revers-Reihenfolge für die vier "betroffenen" Partitionen - an der richtigen Stelle
..\DosDevices\F: - Rechtsklick - umbenennen in ..\CC: [vista]
[..\C: existiert ja noch, also erstmal in ..\CC: umbenennen
..\DosDevices\E: - Rechtsklick - umbenennen in ..\F: [XP_E]
..\DosDevices\D: - Rechtsklick - umbenennen in ..\E: [Swap]
..\DosDevices\C: - Rechtsklick - umbenennen in ..\D: [XP_C]
[und jetzt der Abschluss]
..\DosDevices\CC: - Rechtsklick - .. in ..\C: [vista Endfassung]

... und nach fünf sorgfältig durchgeführten Unbenennungen ist vista heile auf der neuen Festplatte angekommen. Nicht aufwändig - oder?

So simpel kann man auch verfahren, wenn unterschiedliche MS-Installationen auf dem PC vorhanden sind und man will zB. die Laufwerksbuchstaben von USB-Platten anpassen.

PS: Die Systemgewaltigen sollten überlegen, ob die Toppic-Überschrift nicht zusätzlich auf 'vista' erweitert werden sollte - nach meinen Untersuchungen funktioniert sowohl der von koloth beschriebene Lösungsweg als auch die Registry-Umbennen-Lösung beim Umzug von XP und auch vista auf eine neuen Festplatte.
Zieht vista auf die Erweiterte Partition um, so ist bei der Registry-Umbennen-Lösung noch ein wenig Nacharbeit angesagt, dafür funktioniert diese Lösung aber auch dann, wenn die alte Festplatte nicht angeschlossen ist/werden kann, weil sie zum Beispiel defekt ist oder im Notebook kein Platz für eine zweite Festplatte vorhanden ist.
 

Anhänge

  • vista-UUIDs.jpg
    vista-UUIDs.jpg
    51,1 KB · Aufrufe: 406
Koloth,vielen Dank für diese leicht nachzuvollziehende Anleitung. Hab mich auch gleich daran gemacht, mein Systemlaufwerk C: (SCSI Festplatte 10k) auf eine gleichgroße, neue SCSI FP 15k zu kopieren und bin Schritt für Schritt Deiner Anleitung gefolgt. Es sah auch alles ganz gut aus, nur beim ersten Bootvorgang mit noch beiden Platten erscheint im BIOS unter Bootreihenfolge nur 1 FP (C), allerdings werden im BIOS unter "SCSI Controller" beide FP mit Namen aufgeführt.


so schaut die boot.ini aus
Bei 2 Systemen siehe im Beitrag weiter unten.

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect


einfach im editor schreiben bzw bearbeiten und als "boot.ini" unter C:\ abspeichern .

damit die boot.ini angezeigt wird unter Explorer/Extras/Ordneroptionen/Ansicht dann den Haken bei geschützte Systemdateien ausblenden und Versteckte Dateien/Ordner ausblenden entfernen danach auf übernehmen und OK klicken. Anschließend findet man die boot.ini unter C:\
oder Start/Systemsteuerung/Leistung und Wartung/System/Erweitert dann auf Einstellungen bei Starten und wiederherstellen klicken. Danach auf bearbeiten und die Boot.ini entsprechend bearbeiten.

Wenn man z.b. das System auf Platte 1 nachträglich neuinstalliert ist die Boot.ini wieder für nur ein System eingestellt und muss wie hier gezeigt wieder geändert werden damit das 2 System auf der 2 Platte gebootet werden kann. Ist in der boot.ini was falsch eingestellt kommen Meldungen wie hal.dll fehlt oder so ähnlich.


Bei Installation von 2 Systemen auf 2 Festplatten sollte die Boot.ini so eingestellt sein damit man beide Systeme zur Auswahl hat und separat zum booten auswählen kann. " " = Den Namen zwischen den anführungsz. angeben der dann beim booten angezeigt werden soll. Bei Timeout kann man die Zeit in Sekunden angeben die man zum auswählen benötigt.

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Privat" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Gewerbe" /noexecute=optin /fastdetect
 
Zuletzt bearbeitet:
Festplatte kopieren - Lösungsvorschlag

Hallo,

habe auch nach einer Möglichkeit gesucht, eine bootfähige Kopie meiner Festplatte zu machen und so bin ich in diesem Forum gelandet. Da ich ein Anfänger in Sachen Klonen/Partitionierung von Festplatten und ziemlich unter Zeitdruck bin, fand ich es zu aufwendig und unsicher, die Werte in der Windows-Regisrty zu ändern, deswegen habe ich meine eigene unten beschriebene Lösung getestet - mit Erfolg. Für solche Anfänger wie ich hat diese 'Im abgesicherten-Modus-starten'-Lösung (ImaMS) ein Paar Vorteile z.B.:
  • der Kopieraufwand ist gering
  • in der Registry müssen keine Änderungen von Hand gemacht werden
Aufgabenstellung: die Quell-Festpaltte-A (QF-A) vom PC-A zu klonen, damit der PC-B mit der eingebauten Ziel-Festplatte-B (ZF-B) den ausgefallenen PC-A ggf. ersetzen kann. PC-A ist ein Dongle-Server für drei unterschiedliche Anwendungen/Dongles im Netzwerk.

Test 1: mit zwei unterschiedlichen baugleichen PC's, bezeichnet als PC-A und PC-B.
  1. ZF-B formatiert (ZF-B hat nur eine Partition)
  2. QF-A mit DriveImage XML Version 2.13 (Freeware für Privatanwender) im 'Drive to Drive'-Modus in ZF-B mit DriveImage-Standardeinstellungen geklont.
  3. Bemerkung: Nach dem Klonen wird die Partition, auf der ZF-B im Windows-Programm 'Datenträgerverwaltung' als eine normale angezeigt, also ist (noch) keine Systempartition
  4. ZF-B vom PC-A getrennt und im PC-B eingebaut
  5. beim Hochfahren hat Windows mitbekommen, dass die Hardware-Konfiguration geändert wurde und hat ein Auswahlmenü mit der 'Im abgesicherten-Modus-Starten'-Option eingeblendet
  6. habe die Option 'Im abgesicherten-Modus-Starten' ausgewählt, Windows im abgesicherten Modus gestartet
  7. nach erfolgreichem Start habe den PC heruntergefahren und neu gestartet
  8. ein Menü wurde eingeblendet, wo Windows empfiehl, das Programm CHKDSK laufen zu lassen
  9. bin der Empfehlung gefolgt, und CHKDSK hat automatisch einige Dateien gelöscht/wiederhergestellt
  10. jetzt ist die ZF-B-Partition zu einer Systempartition geworden
  11. Fertig!!!
Keine manuelle Änderungen in der Registry, kein ISO-Image, keine Experten-Kenntnisse notwendig :) Vermutlich passt Windows einige Einstellungen, die in früheren Beiträgen in diesem Thread händisch gemacht werden, in der ImaMS-Lösung automatisch an.

Anmerkungen:
- getestet mit Windows XP SP3
- meine ZF-B-Partition ist größer, als QF-A-Partition, aber ich gehe davon aus, dass es unerheblich ist, Hauptsache die ZF-B ist nicht kleiner, als QF-A

Edit 27.05.2010
Test 2: die geklonte Festplatte ZF-B wird im gleichen PC-C, wie QF-A für's Booten verwendet:
Habe jetzt einen zweiten Test durchgeführt, wobei die ZF-B im Unterschied zum Test 1 zwei Partitions ZF-B-X und ZF-B-Y hat. Test 2 hat gezeigt - wenn ZF-B-X nicht als aktive Partition festgelegt wird - s. Schritt 4 unten - dann scheitert der Windows-Start, wobei das BIOS meldet, dass kein bootfähiger Datenträger gefunden wurde. Schritte 5 bis 7 aus dem Test 1 waren im Test 2 überflüssig, da Windows keine Änderungen der Hardware-Konfiguration festgestellt hat und entsprechend kein 'Im abgesicherten-Modus-Start' notwendig ist.

  1. ZF-B-X formatiert (Schnellformatierung bei der Erstellung der Partition im Programm 'Datenträgerverwaltung')
  2. QF-A mit DriveImage XML Version 2.13 (Freeware für Privatanwender) im 'Drive to Drive'-Modus in ZF-B-X mit DriveImage-Standardeinstellungen geklont.
  3. Bemerkung: Nach dem Klonen wird die Partition, auf der ZF-B-X im Windows-Programm 'Datenträgerverwaltung' als eine normale angezeigt, also ist (noch) keine Systempartition
  4. habe die Partition ZF-B-X in der Datenträgerverwaltung als aktiv festgelegt (auf die Partition klicken und im Rechtsklick-Menü 'Partition als aktiv markieren' auswählen).
  5. QF-A wird vom PC-C getrennt
  6. ZF-B wird in den PC-C an Stelle der QF-A eingebaut
  7. PC-C hochgefahren
  8. ein Menü wurde eingeblendet, wo Windows empfiehlt, das Programm CHKDSK laufen zu lassen
  9. bin der Empfehlung gefolgt, und CHKDSK hat automatisch einige Dateien gelöscht//wiederhergestellt
  10. jetzt ist die ZF-B-X-Partition zu einer Systempartition geworden
  11. Fertig!!!
 
Zuletzt bearbeitet:
Dass das so kompliziert ist hätte ich nicht gedacht, ich hatte immer die neu Festplatte in das zu klonende Windows eingebaut, einmal Windows gestartet, Platte geklont und fertig.
Hat meistens funktioniert.
 
Laufwerk mit XP Systempartition austauschen.

Hallo,

da dieses Forum mir mit seinen Beiträgen sehr geholfen hat möchte ich kurz die Anleitung von "Supporter" bestätigen und eine Art Schritt für Schritt Anleitung geben. Das Laufwerk mit der Windows XP Systempartition kann also problemlos durch ein neues Laufwerk ersetzt werden, oder eine bootfähige Sicherungskopie der Windowsinstallation ("C") ist gewüscht.
Einfache Images einer Systempartion unter XP z.B. auf einem beliebigen externen Datenspeicher sind nur solange ohne Einschränkungen brauchbar, wie der ursprüngliche Datenträger verwendet wird, um das Image wieder herzustellen. Fällt die Festplatte komplett aus, ist es vorteilhaft eine zweite Festplatte im Schrank zu haben um die defekte auszutauschen.

Hier die Vorgehensweise für eine SATAII - Festplatte:
Kaufen Sie eine neue Festplatte (am einfachsten die gleiche) oder eine größere falls das Laufwerk "C" gleich noch vergrößert werden soll. Es kann auch ein anderer Hersteller gekauft werden.
Schießen Sie die Festplatte an einen weiteren freien SATA-Platz des Computers an.

Starten sie den PC > öffne mit Rechtsklick auf "Arbeitsplatz" die Verwaltung von Windows-XP. Unter "Datenträgerverwaltung" ist das neue Laufwerk angezeigt. Es wird hier zunächst "initialisiert" (Rechtsklick auf den Balken der das LW repräsentiert) aber nicht in ein Dynamisches Laufwerk konvertiert. Den Haken hier im Folgedialog also nicht setzten, somit wird das Laufwerk als Basisdatenträger angelegt
Danach wird eine Primäre Partition - wichtig: ohne Zuordnung eines Laufwerkbuchstabens - erstellt mit mindestens ausreichender Größe um das System darauf zu kopieren.

Jetzt kann am besten im Disk-to-Disk Verfahren die Systempartition auf die neue Partition kopiert werden. Bei der Verwendung von DriveImageXML ist es nicht notwendig den RAW-Modus zu verwenden. Ich persöhnlich verwende die Ultimate-Boot-CD auf der DriveImageXML enthalten ist und kopiere im Locking-Modus (Windows wird von CD ausgeführt, wodurch die Systempartition "C" direkt kopiert wird). Wie bei "Suppporter" beschieben geht es aber auch im Shadow-Modus bei laufendem System.

Nach Abschluss der Disk-to-Disk Kopie, wird das System nochmal hochgefahren, oder ist immer noch hochgefahren wenn keine Ultimate-Boot-CD verwendet wurde. In der Datenträgerverwaltung wird die neue Partition "aktiv" geschaltet (Rechtsklick auf den Laufwerksbalken). Auch hier keinen Laufwerksbuchstaben vergeben.

Der PC wird nun herunter gefahren und das neue Laufwerk an das SATA-Kabel der alten Systemfestplatte angeschlossen. Die alte Systemplatte kann entfernt werden.

Windows starten > fertig.
Windows vergibt den Laufwerksbuchstaben "C" automatisch der neuen Platte und startet genau wie von der alten.

Bei meiner Systemsicherung wurde weder gemeckert noch "chkdisk" ausgeführt sonder genauso gestartet wie von der alten Platte, was eventuell am Locking-Modus beim Disk-to-Disk kopieren lag.

achimudo
 
Oben