XP in Domäne als VM geklont, Original nun nicht mehr in Dom?

[klaymen]

Wie in http://vmware.itst.org/viewtopic.php?t=2991 beschrieben, habe ich neulich ein bestehendes XP Pro System (einer Multiboot-Konfiguration) in eine VM geklont, indem ich ein Disk Image anlegte, dieses in die virtuelle Disk der VM zurückspielte und dann mit MergeIDE impfte. Bei dem System handelt es sich um ein System in einer Domäne mit AD. Die alte Partition habe ich beibehalten, so dass ich wahlweise im Multiboot direkt oder in der VM booten kann (wobei in der VM eine Kopie der Originaldisk liegt, nicht die Raw Disk selber - das wagte ich im Moment nicht). Zusammengefasst also:

Disk 1 mit Original-OS ("A"), in Domäne mit AD

Disk 2 mit zweitem XP Pro ("B") als Multiboot zu "A"

In "B" VMWare installiert mit virtueller Disk, die ein Image der Systemdisk von "A" bekam und mit MergeIDE behandelt wurde: System "C", ein Klon von "A"

An sich klappte das auch prima, bloss... seit heute kann ich beim Booten aus der ORIGINAL-Partition ("A") nicht mehr in die Domäne einloggen. Das System beklagt sich nach Eingabe von UserID und Passwort, dass es den Domänencontroller nicht fände, oder dass es meinen Account nicht gäbe - ohne sich auf das Eine oder Andere festlegen zu wollen. Wenn ich mich allerdings genau gleich in der VM einlogge ("C"), klappt alles Bestens - der fehlende Account kann es also nicht sein. Das ist zwar keine Katastrophe, da ich in der VM ja arbeiten kann - aber es wäre mir deutlich wohler, wenn meine Originalinstallation auch noch liefe. Komischerweise haben beide Systeme eine Zeit lang parallel funktioniert. Wann genau das Original nicht mehr ging, weiss ich nicht, weil ich mich selten in "A" einloggte. Möglicherweise entstand das Problem, als ich in "C" die VMWare-Tools installierte, aber das ist nur Spekulation.

Ich kann nur vermuten, dass durch irgendeinen Mechanismus die Computer SID geändert wurde und so die Original-Partition aus der Domäne geschmissen wurde... aber ich bin ziemlich ratlos, was da geschehen ist. Hat jemand eine Ahnung? Wie gesagt funktioniert die VM-Installation problemlos weiter - im umgekehrten Fall hätte ich es ja noch verstanden.

Was ich natürlich jetzt probieren könnte, wäre, den umgekehrten Weg zu gehen und das virtuelle System wieder in eine neue Partition des physikalischen systems zu migrieren, also Image anlegen und dann auf einer physischen Partition restoren. Würde sowas funktionieren? Hardware habe ich nichts Spezielles, und da es sich bei unserem XP um eine "Geschäftslizenz" handelt, ist keine Aktivierung notwendig (war es noch nie). Im Idealfall könnte ich dann diese physikalische Partition direkt zum Booten einer VM nutzen (als Raw Disk), aber da weiss ich nicht, ob ich es wagen soll... auf jeden Fall wollte ich erst mal nachfragen, was hinter der Sache stecken könnte, und was ihr dazu meint.

Theoretisch wäre es auch denkbar, dass auf der VM durch eine automatische Installation (wir haben Centennial und Columbus auf unseren Systemen, so dass manchmal nach dem Einloggen etwas geupdatet wird) in der VM ("C") deren SID (oder andere Daten) so geändert wurde, dass von der Domäne das "Original" ("A") nicht mehr als zur Domäne gehörend akzeptiert wird. In dem Fall wäre es natürlich prima, wenn man für Originalsystem und VM-Klon dieselbe (raw) Partition nutzen könnte...[/list]

[continuum]

Hi
schade dass du nicht nachvollziehen kannst, seit wann es genau nicht mehr geht. Ich tippe mal darauf, dass es in dem Moment 'auffiel'
als A sich einmal in der Domain einloggte als C nicht angemeldet war. Als C neu hinzukam hat sich die Domain wahrscheinlich etwas ueber die neue MAC gewundert - das aber wahrscheinlich als normale Aenderung der Hardware angesehen. Als dann beim einloggen von A die alte MAC wieder auftauchte wurde die Domain misstrauisch und hat geblockt. Ich weiss nicht ob man diese etrwas anthropomorphe Sichtweise hier anwenden kann aber ein DC ist schliesslich auch nur ein Mensch.

Also meines Wissens sollten A und C immer noch die selben SIDs haben - es sei denn du haettest das bewusst geaendert.
Ich schaetze auch dass es nichts nuetzen wuerde, die VM von der selben raw-disk laufen zu lassen wie A. Die MAC wuerde sich trotzdem aendern und die Domain wuerde merken, dass es nicht derselbe Computer ist.

Du fragst nach V2P - dass ist im Prinzip dieselbe Vorgehensweise - mit dem Unterschied, dass die Zielhardware nicht so allgemein bekannt ist wie im umgekehreten Fall - deswegen muesstest du dir dein Rueckkehrpatch selber machen - was aber in diesem Fall nicht so schwierig sein sollte, da du ja ein quasi identisches System auf beiden Plattformen am laufen hast.

Du muesstest dir halt beide HKLM\system\controlset001 nehmen und die Datei-unterschiede raussuchen und daraus ein Patch machen. Wenn du Lust auf das Experiment hast - schick mir mal beide zu und ich gucke mal was sich machen laesst - ich habe das schon ein paarmal gemacht - das erste Mal dauert ewig - danach weiss man ungefaehr wo es drauf ankommt.

Ulli

[klaymen]

So, nun läuft's wieder ;--) Ich habe auch zuerst gedacht, es liege eventuell an der MAC-Adresse (was aber komisch wäre, da der DC ja die Mac-Adresse gar nicht sieht wegenRoutern dazwischen). Ich habe den Netzverkehr mal gesniffed und dabei festgestellt, dass bei der Originalinstallation offenbar die Netlogon-Prozedur scheitert, bei der sich Maschine und DC gegenseitig authentifizieren und einen sicheren Kanal aufbauen ("NetrServerAuthenticate3"). Ich vermute mal, dass es eine Policy gibt, welche die Clientmaschine periodisch (monatlich oder so) anweist, ihre Credentials zu ändern - und sobald das geschah, konnte sich die Originalinstallation nicht mehr authentifizieren. Ich habe versucht, herauszufinden, wo in der Registry die neuen Credentials sind, konnte das aber bislang nicht eruieren (netlogon.flt war es auf jeden Fall nicht). Ich habe dann schliesslich die Registryhives allesamt (ausser dem software-Hive) von der virtuellen Installation in die echte rüberkopiert, und nun klappt es wieder. Ich habe auch noch Snapshots angelegt und hoffe so, beim nächsten Mal die Stelle genauer eruieren zu können...