2
Custom-ISO mit integr. Treibern macht Probleme als VM, kann das sein, kennt das jemand?
Hallo.
Ich erstelle unregelmäßig, aber mehrmals pro Jahr meine eigenen ISOs für die hier im Einsatz befindlichen Clientsysteme (7, 10). Das erledige ich mit Hilfe einer virtuellen Maschine unter VMware. Klappt wunderbar, ich installiere alle Updates, syspreppe die Maschine dann und ziehe sie dann mittels WAIK i. V. m. gImageX ab.
Die so erhaltene install.wim pimpe ich dann noch mittels DISM (hiernach :https://technet.microsoft.com/de-de/library/dd744355(v=ws.10).aspx#AddDr ... mit den aktuellen Treibern unserer Hardware. Dann kopiere ich die install.wim zurück in die entpackte ursprüngliche ISO und mache aus dem Verzeichnis mit Hilfe von ImgBurn wieder eine bootfähige ISO.
Das klappte bislang wunderbar.
Ist die neue ISO dann fertig, "haue" ich sie nochmal neu in eine VM, um letztgültig ersehen zu können, ob das so nun in Ordnung ist. Und jetzt kriege ich aber heftige Fehler, mitten im Windows-Setup kommen Blackscreens mit Treiber-Fehlermeldungen, die dem Namen nach eindeutig mit den per DISM integrierten Hardwaretreibern zu tun haben.
Nun meine Frage:
Warum werden die integrierten Treiber, die ich für unsere physische Hardware mit integriert habe, beim Windows-Setup in einer virtuellen Maschine unter VMware überhaupt angesprochen? In der VM ist doch gar keine (virtuelle) Hardware enthalten, für die diese Treiber Geltung hätten? Immerhin läßt sich Windows ja in einer VM installieren, ohne daß es zunächst überhaupt irgendeines Treibers bedarf, also auch noch vor der Installation der VMware Tools. Warum rotzen hier Treiber mit rein, die das System in meinem Test unter VMware gar nicht braucht?
Wäre klasse, wenn jemand etwas dazu wüßte.
Danke Euch erstmal.
Viele Grüße
von
departure69
Ich erstelle unregelmäßig, aber mehrmals pro Jahr meine eigenen ISOs für die hier im Einsatz befindlichen Clientsysteme (7, 10). Das erledige ich mit Hilfe einer virtuellen Maschine unter VMware. Klappt wunderbar, ich installiere alle Updates, syspreppe die Maschine dann und ziehe sie dann mittels WAIK i. V. m. gImageX ab.
Die so erhaltene install.wim pimpe ich dann noch mittels DISM (hiernach :https://technet.microsoft.com/de-de/library/dd744355(v=ws.10).aspx#AddDr ... mit den aktuellen Treibern unserer Hardware. Dann kopiere ich die install.wim zurück in die entpackte ursprüngliche ISO und mache aus dem Verzeichnis mit Hilfe von ImgBurn wieder eine bootfähige ISO.
Das klappte bislang wunderbar.
Ist die neue ISO dann fertig, "haue" ich sie nochmal neu in eine VM, um letztgültig ersehen zu können, ob das so nun in Ordnung ist. Und jetzt kriege ich aber heftige Fehler, mitten im Windows-Setup kommen Blackscreens mit Treiber-Fehlermeldungen, die dem Namen nach eindeutig mit den per DISM integrierten Hardwaretreibern zu tun haben.
Nun meine Frage:
Warum werden die integrierten Treiber, die ich für unsere physische Hardware mit integriert habe, beim Windows-Setup in einer virtuellen Maschine unter VMware überhaupt angesprochen? In der VM ist doch gar keine (virtuelle) Hardware enthalten, für die diese Treiber Geltung hätten? Immerhin läßt sich Windows ja in einer VM installieren, ohne daß es zunächst überhaupt irgendeines Treibers bedarf, also auch noch vor der Installation der VMware Tools. Warum rotzen hier Treiber mit rein, die das System in meinem Test unter VMware gar nicht braucht?
Wäre klasse, wenn jemand etwas dazu wüßte.
Danke Euch erstmal.
Viele Grüße
von
departure69
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 317021
Url: https://administrator.de/contentid/317021
Printed on: April 26, 2024 at 18:04 o'clock
2 Comments
Latest comment
Hallo,
per DISM eingepflanzte Treiber sollte man nur auf die grundlegenden wie z.B. Host-Controller-Treiber begrenzen die für den erfolgreichen Start benötigt werden und weitere Treiber erst später per Systembeaufsichtigungsmodus vor dem Sysprep einrichten.
R.
per DISM eingepflanzte Treiber sollte man nur auf die grundlegenden wie z.B. Host-Controller-Treiber begrenzen die für den erfolgreichen Start benötigt werden und weitere Treiber erst später per Systembeaufsichtigungsmodus vor dem Sysprep einrichten.
R.
@131026:
Vielen Dank für Deine Antwort. Daran liegt es aber nicht. Hab' jetzt herausgefunden, woran es lag. Es macht nichts, alle Sorten von Treibern da mitreinzuballern, das hat in der Vergangenheit auch kein Problem gemacht, nein, es lag daran, daß ich diesmal mal wieder die allerneuesten Treiber frisch gesaugt habe (von Fujitsu). In manchen Treiberpaketen befinde sich nach dem entpacken aber die 64- und die 32-Bit-Version, was ich erst jetzt bemerkt hab'. Hab' den Vorgang jetzt nochmal wiederholt, die 32-Bit-Versionen der Treiber entfernt und voila, plötzlich funktioniert auch der Test der neuen Custom-ISO in der virtuellen Maschine (bzw. es hatte mit der VM auch gar nichts zu tun, auch auf echter Hardware wäre ich in diese Setup-Fehlermeldung gelaufen).
Viele Grüße
von
departure69
Vielen Dank für Deine Antwort. Daran liegt es aber nicht. Hab' jetzt herausgefunden, woran es lag. Es macht nichts, alle Sorten von Treibern da mitreinzuballern, das hat in der Vergangenheit auch kein Problem gemacht, nein, es lag daran, daß ich diesmal mal wieder die allerneuesten Treiber frisch gesaugt habe (von Fujitsu). In manchen Treiberpaketen befinde sich nach dem entpacken aber die 64- und die 32-Bit-Version, was ich erst jetzt bemerkt hab'. Hab' den Vorgang jetzt nochmal wiederholt, die 32-Bit-Versionen der Treiber entfernt und voila, plötzlich funktioniert auch der Test der neuen Custom-ISO in der virtuellen Maschine (bzw. es hatte mit der VM auch gar nichts zu tun, auch auf echter Hardware wäre ich in diese Setup-Fehlermeldung gelaufen).
Viele Grüße
von
departure69