108129
25.11.2014, aktualisiert um 13:01:31 Uhr
2564
16
0
Probleme bei Installation Windows Server 2008 R2 mit in Image integrierten Windows Updates auf VMware ESX 5.1 Update 2
Hallo Community,
ich habe folgendes Problem:
Um Zeit bei der Neuinstallation von Windows Server 2008 R2 sparen zu können, wurden Windows Updates mit dem Tool DISM in das von der Installations-DVD kopierte Betriebssystem-Image install.wim integriert.
Die Neuinstallation von Hardware-Server jeglicher von uns eingesetzter Hardware-Type und auch in unserer VMware Workstation Laborumgebung mit diesem Image funktioniert ohne Fehler.
Die Installation des Betriebssystem auf einem ESX-Host bleibt aber bei der Phase "Completing Installation ..." hängen.
Danke für eure Hilfe im Voraus, Gruß Markus
ich habe folgendes Problem:
Um Zeit bei der Neuinstallation von Windows Server 2008 R2 sparen zu können, wurden Windows Updates mit dem Tool DISM in das von der Installations-DVD kopierte Betriebssystem-Image install.wim integriert.
Die Neuinstallation von Hardware-Server jeglicher von uns eingesetzter Hardware-Type und auch in unserer VMware Workstation Laborumgebung mit diesem Image funktioniert ohne Fehler.
Die Installation des Betriebssystem auf einem ESX-Host bleibt aber bei der Phase "Completing Installation ..." hängen.
- Könnte der Fehler durch ein bereits im Vorhinein installiertes Windows Update mit der Suche nach Treibern in dieser Phase der Betriebssysteminstallation zusammenhängen?
- Gibt es von Seiten VMware womöglich eine Information, welche Windows Updates sich nicht mit VMware ESX 5.1 Update 2 "vertragen"?
- Könnte es vielleicht noch einen anderen Grund geben, hatte schon mal jemand ein ähnliches Problem?
Danke für eure Hilfe im Voraus, Gruß Markus
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 255827
Url: https://administrator.de/forum/probleme-bei-installation-windows-server-2008-r2-mit-in-image-integrierten-windows-updates-auf-vmware-esx-5-1-255827.html
Ausgedruckt am: 31.05.2025 um 08:05 Uhr
16 Kommentare
Neuester Kommentar
Hi.
Es ist mehr als unwahrscheinlich, dass es die integrierten Updates sind. Die install.wim, ein Imageformat, wird ja nur entpackt. Das hat mit gerätespezifischer Erkennung nichts zu tun.
Aber: man weiß nie. Sorry, hilft nicht großartig, ich weiß.
Habe noch nichts dergleichen mit integrierten Installationen erlebt, arbeite damit auch unter ESXI 5.1/5.5.
Es ist mehr als unwahrscheinlich, dass es die integrierten Updates sind. Die install.wim, ein Imageformat, wird ja nur entpackt. Das hat mit gerätespezifischer Erkennung nichts zu tun.
Aber: man weiß nie. Sorry, hilft nicht großartig, ich weiß.
Habe noch nichts dergleichen mit integrierten Installationen erlebt, arbeite damit auch unter ESXI 5.1/5.5.
Hallo.
Welche Windows Updates wurden integriert? Ich arbeite eigentlich auch so, daß ich nur ISOs verwende, die ich vorher mit allen Updates bis zum aktuellen Zeitpunkt versorgt habe. Allerdings verwende ich dazu nicht DISM, sondern Sysprep i. V. m. dem Capture-Befehl aus ImageX, dann die "install.wim" in die orginale Quelle ("Sources"-Ordner) zurückkopieren, die bestehende install.wim dabei überschreiben und die ISO dann mit ImgBurn dann neu bootfähig erstellen. Läuft aber auf's selbe hinaus.
Ich hatte auch schon den Fall, daß der Dialog "Installation wird beendet" in einer virtuellen Maschine auch nach Stunden nicht weitermachte. Ich hab' lange gebraucht und viel versucht, bis ich den Fehler raushatte:
Ich hatte nicht nur die Windows Updates integriert, die auch standardmäßig über Windows Update (oder den WSUS) kommen würden, sondern auch jede Menge Hotfixes. Hotfixes für schnelleres USB, Hotfixes für besseres Aufwachen aus dem Standby, Hotfix für Printserver, wenn eine Treiberaktualisierung nicht oder nicht richtig will, Hotfix für Scannerbetrieb und viele weitere mehr (ca. 2 Dutzend). Diese Hotfixe hatte ich über Jahre für Windows 7und Windows Server 2008R2 zusammengesammelt und aufgehoben, weil diese nie im SP1 gelandet waren und von Microsoft auch nie als reguläre Updates veröffentlicht wurden.
Heute weiß ich, daß es völlig unnötig oder sogar schädlich ist, diese Hotfixe zu installieren (oder in einem vorgefertigten Image mit bereitzustellen), da diese Hotfixe nur für Fälle gedacht sind, wo das beschriebene Problem (also bspw. kein Aufwachen aus dem Standby usw.) wirklich vorliegt. Rechner oder Server, bei denen diese Probleme gar nicht bestehen, brauchen diese Hotfixe gar nicht, obendrein kann sogar die Installation beschädigt oder zumindest deren Verhalten verschlechtert werden.
Danach habe ich nur noch all das integriert, was auch wirklich von allein über Windows Update hereinkommt, und schon haben die Images in virtuellen Maschinen funktioniert (bei mir allerdings nicht in ESX(i), sondern unter HYPER-V).
Somit die Frage an Dich:
Ist in dem Image irgendwas drin, was nicht hineingehört? Falls Du nicht sicher bist: Integrier doch mal auf Basis einer frisch heruntergeladenen Microsoft-VL-ISO und verwende dabei nur die Updates, die WU von alleine bringt, und sonst nichts weiter (wobei es mich persönlich reizen würde, sogleich die VMware-Tools mit zu integrieren
).
Viele Grüße
von
departure69
Welche Windows Updates wurden integriert? Ich arbeite eigentlich auch so, daß ich nur ISOs verwende, die ich vorher mit allen Updates bis zum aktuellen Zeitpunkt versorgt habe. Allerdings verwende ich dazu nicht DISM, sondern Sysprep i. V. m. dem Capture-Befehl aus ImageX, dann die "install.wim" in die orginale Quelle ("Sources"-Ordner) zurückkopieren, die bestehende install.wim dabei überschreiben und die ISO dann mit ImgBurn dann neu bootfähig erstellen. Läuft aber auf's selbe hinaus.
Ich hatte auch schon den Fall, daß der Dialog "Installation wird beendet" in einer virtuellen Maschine auch nach Stunden nicht weitermachte. Ich hab' lange gebraucht und viel versucht, bis ich den Fehler raushatte:
Ich hatte nicht nur die Windows Updates integriert, die auch standardmäßig über Windows Update (oder den WSUS) kommen würden, sondern auch jede Menge Hotfixes. Hotfixes für schnelleres USB, Hotfixes für besseres Aufwachen aus dem Standby, Hotfix für Printserver, wenn eine Treiberaktualisierung nicht oder nicht richtig will, Hotfix für Scannerbetrieb und viele weitere mehr (ca. 2 Dutzend). Diese Hotfixe hatte ich über Jahre für Windows 7und Windows Server 2008R2 zusammengesammelt und aufgehoben, weil diese nie im SP1 gelandet waren und von Microsoft auch nie als reguläre Updates veröffentlicht wurden.
Heute weiß ich, daß es völlig unnötig oder sogar schädlich ist, diese Hotfixe zu installieren (oder in einem vorgefertigten Image mit bereitzustellen), da diese Hotfixe nur für Fälle gedacht sind, wo das beschriebene Problem (also bspw. kein Aufwachen aus dem Standby usw.) wirklich vorliegt. Rechner oder Server, bei denen diese Probleme gar nicht bestehen, brauchen diese Hotfixe gar nicht, obendrein kann sogar die Installation beschädigt oder zumindest deren Verhalten verschlechtert werden.
Danach habe ich nur noch all das integriert, was auch wirklich von allein über Windows Update hereinkommt, und schon haben die Images in virtuellen Maschinen funktioniert (bei mir allerdings nicht in ESX(i), sondern unter HYPER-V).
Somit die Frage an Dich:
Ist in dem Image irgendwas drin, was nicht hineingehört? Falls Du nicht sicher bist: Integrier doch mal auf Basis einer frisch heruntergeladenen Microsoft-VL-ISO und verwende dabei nur die Updates, die WU von alleine bringt, und sonst nichts weiter (wobei es mich persönlich reizen würde, sogleich die VMware-Tools mit zu integrieren
).Viele Grüße
von
departure69
Hallo,
Danke für deine ausführliche Info.
Ich habe einfach ein "jungfräuliches" Image (install.wim) von der Installations-DVD kopiert, Windows Updates der Kategorien Critical / Security Updates heruntergeladen und eben mit DISM in das Image integriert.
Da waren keine Hotfixes dabei, darauf habe ich extra geachtet, da die Freigabe und Installation von Hotfixes einem anderen Fachbereich in unserem Unternehmen obliegt.
Ich konnte aber gestern noch über die Panther-Logs unter "C:\Windows\Panther" Folgendes herausfinden:
Im File "C:\Windows\Panther\UnattendGC\setuperr.log" steht
[DJOIN.EXE] Unattended Join: NetJoinDomain failed error code is [1355]
[DJOIN.EXE] Unattended Join: Unable to join, gdwError = 0x54b
und im Device Manager wird der Ethernet Controller mit dem gelben Rufezeichen dargestellt. Demnach dürfte es hier in der Phase "Completing Installation ..." ein Problem mit der Installation der Treibers für die Netzwerkkarte geben.
Doch durch welches Update wird dieser Fehler verursacht? Ist dies dann ein generelles Problem mit dem Driverstore, oder verträgt sich das Update konkret nicht mit dem Treiber der verbauten NIC? usw.
Gruß Markus
Danke für deine ausführliche Info.
Ich habe einfach ein "jungfräuliches" Image (install.wim) von der Installations-DVD kopiert, Windows Updates der Kategorien Critical / Security Updates heruntergeladen und eben mit DISM in das Image integriert.
Da waren keine Hotfixes dabei, darauf habe ich extra geachtet, da die Freigabe und Installation von Hotfixes einem anderen Fachbereich in unserem Unternehmen obliegt.
Ich konnte aber gestern noch über die Panther-Logs unter "C:\Windows\Panther" Folgendes herausfinden:
Im File "C:\Windows\Panther\UnattendGC\setuperr.log" steht
[DJOIN.EXE] Unattended Join: NetJoinDomain failed error code is [1355]
[DJOIN.EXE] Unattended Join: Unable to join, gdwError = 0x54b
und im Device Manager wird der Ethernet Controller mit dem gelben Rufezeichen dargestellt. Demnach dürfte es hier in der Phase "Completing Installation ..." ein Problem mit der Installation der Treibers für die Netzwerkkarte geben.
Doch durch welches Update wird dieser Fehler verursacht? Ist dies dann ein generelles Problem mit dem Driverstore, oder verträgt sich das Update konkret nicht mit dem Treiber der verbauten NIC? usw.
Gruß Markus
Moin,
steht in der C:\Windows\debug\NetSetup.LOG noch etwas dazu ? Weil der Fehler deutet ja auf Probleme beim joinen der Domain hin. In der Regel ist also ein Netzwerkfehler die eigentliche Ursache (oder falsche Anmeldedaten für die Domain)
Welche Virtuell Netzwerk-Karte wird genutzt ? Und wird die auch beim Start verbunden ? (manchmal sind es ja die ganz banalen Fehler, die einem das Leben schwer machen
)
Gruß
Bernhard
steht in der C:\Windows\debug\NetSetup.LOG noch etwas dazu ? Weil der Fehler deutet ja auf Probleme beim joinen der Domain hin. In der Regel ist also ein Netzwerkfehler die eigentliche Ursache (oder falsche Anmeldedaten für die Domain)
Welche Virtuell Netzwerk-Karte wird genutzt ? Und wird die auch beim Start verbunden ? (manchmal sind es ja die ganz banalen Fehler, die einem das Leben schwer machen
)Gruß
Bernhard
Hallo,
den Fehler mit dem nicht erfolgten DomainJoin konnte ich wirklich auf das Fehlen eines Netzwerktreibers bei dieser Phase des Windows Setups zurückführen. Ich konnte aber leider nicht herausfinden, warum es gerade bei diesem ESX-Host das Problem gab.
Erste Hürde gepackt, nun kommt eine zweite:
Die Betriebssysteminstallation bleibt nach wie vor in der Phase "Completing Installation ..." hängen.
Im "C:\Windows\Panther\UnattendGC\setupact.log" steht als letztes der Eintrag
[IE Unattend] Exiting 'specialize' pass with status 0x80070002
Ich hatte zwei Windows Updates für den IE integriert, welche ich aber dann wieder entfernt habe. Ich habe nochmals das Basisimage kopiert und die Windows Updates OHNE besagter IE Updates erneut integriert.
Leider brachte dies auch keinen Erfolg.
Irgendwelche weiteren Ideen?
Ich setze mittlerweile den Server "normal" auf, die anschließend nicht mehr benötigten Software-Pakete werden wieder entfernt und anschließend ziehe ich ein Image mit dem Tool ImageX.
Sauberer wäre aber für mich das Basisimage der Installations-DVD + integrierte Windows Updates ...
Gruß Markus
den Fehler mit dem nicht erfolgten DomainJoin konnte ich wirklich auf das Fehlen eines Netzwerktreibers bei dieser Phase des Windows Setups zurückführen. Ich konnte aber leider nicht herausfinden, warum es gerade bei diesem ESX-Host das Problem gab.
Erste Hürde gepackt, nun kommt eine zweite:
Die Betriebssysteminstallation bleibt nach wie vor in der Phase "Completing Installation ..." hängen.
Im "C:\Windows\Panther\UnattendGC\setupact.log" steht als letztes der Eintrag
[IE Unattend] Exiting 'specialize' pass with status 0x80070002
Ich hatte zwei Windows Updates für den IE integriert, welche ich aber dann wieder entfernt habe. Ich habe nochmals das Basisimage kopiert und die Windows Updates OHNE besagter IE Updates erneut integriert.
Leider brachte dies auch keinen Erfolg.
Irgendwelche weiteren Ideen?
Ich setze mittlerweile den Server "normal" auf, die anschließend nicht mehr benötigten Software-Pakete werden wieder entfernt und anschließend ziehe ich ein Image mit dem Tool ImageX.
Sauberer wäre aber für mich das Basisimage der Installations-DVD + integrierte Windows Updates ...
Gruß Markus
Hallo Markus.
Deine imagex-Methode ist genau so sauber, oder warum denkst Du anders?
Deine imagex-Methode ist genau so sauber, oder warum denkst Du anders?
Vielleicht habe ich mich hier falsch ausgedrückt:
Der Server wird über unser eingesetztes Softwareverteilungstool und nicht mittels Installations-DVD neu aufgesetzt, dadurch wird auch eigentlich im Image nicht benötigte Software auch mitinstalliert. Im Nachhinein muss ich ein wenig aufräumen (Registry-Einträge, Programmorder etc.), um das Betriebssystem so halbwegs sauber zu bekommen, das meinte ich damit.
Der Server wird über unser eingesetztes Softwareverteilungstool und nicht mittels Installations-DVD neu aufgesetzt, dadurch wird auch eigentlich im Image nicht benötigte Software auch mitinstalliert. Im Nachhinein muss ich ein wenig aufräumen (Registry-Einträge, Programmorder etc.), um das Betriebssystem so halbwegs sauber zu bekommen, das meinte ich damit.
Verstehe.
Mach es so: installiere den Server in der VM nackt und naturbelassen. Installiere dann alle Updates. Fahre ihn runter, mounte die VHD(x) in einem anderen System und mache einen Abzug mit Imagex. Nun kannst Du die install.wim, die dabei entsteht wunderbar auf Deinen Installations-USB-Stick in den Ordner Sources legen und damit Server gepatcht installieren. Willst Du das auch als ISO haben, sind weitere Schritte mit ISO-Tools erforderlich, aber es geht lediglich um den Austausch dieser .wim-Datei.
Mach es so: installiere den Server in der VM nackt und naturbelassen. Installiere dann alle Updates. Fahre ihn runter, mounte die VHD(x) in einem anderen System und mache einen Abzug mit Imagex. Nun kannst Du die install.wim, die dabei entsteht wunderbar auf Deinen Installations-USB-Stick in den Ordner Sources legen und damit Server gepatcht installieren. Willst Du das auch als ISO haben, sind weitere Schritte mit ISO-Tools erforderlich, aber es geht lediglich um den Austausch dieser .wim-Datei.
Sooo, ich habe, wie von "DerWoWusste" vorgeschlagen, die VM mittels Installations-DVD neu installiert, dort die Windows Updates installiert und anschließend ein Image mittels ImageX gezogen.
Die "alte" install.wim habe ich durch die neue, von ImageX erzeugte install.wim ersetzt.
Doch nun stehe ich wieder vor einem anderen Problem. Bei der Neuinstallation des Servers mit der neuen install.wim kann beim Windows Setup keine Edition (Server Standard, Server Enterprise, Core etc.) des OS gefunden werden. Ich habe bei der Erstellung des Image bereits folgende Parameter für ImageX im Test verwendet ->
ImageX.exe /capture <Systempartition> <Ziel>:\install.wim "System" /flags "ServerStandard" /compress maximum /verify
oder
ImageX.exe /capture <Systempartition> <Ziel>:\install.wim "System" /compress maximum /verify
Egal, ob ich den Parameter für Flags setze oder auch nicht, beim Windows Setup hat die install.wim keine Information über die Edition des OS.
Die "alte" install.wim habe ich durch die neue, von ImageX erzeugte install.wim ersetzt.
Doch nun stehe ich wieder vor einem anderen Problem. Bei der Neuinstallation des Servers mit der neuen install.wim kann beim Windows Setup keine Edition (Server Standard, Server Enterprise, Core etc.) des OS gefunden werden. Ich habe bei der Erstellung des Image bereits folgende Parameter für ImageX im Test verwendet ->
ImageX.exe /capture <Systempartition> <Ziel>:\install.wim "System" /flags "ServerStandard" /compress maximum /verify
oder
ImageX.exe /capture <Systempartition> <Ziel>:\install.wim "System" /compress maximum /verify
Egal, ob ich den Parameter für Flags setze oder auch nicht, beim Windows Setup hat die install.wim keine Information über die Edition des OS.
Hallo.
ich hab' mich mit den möglichen Parametern zum ImageX-Befehl auch schon vielfach erfolglos herumgequält. Bis ich dann endlich entdeckt hatte, daß ein freundlicher Mensch mal eine GUI dafür programmiert hat, zumindest für mich als Mausschubser-Admin ideal. Dort kann ich bspw. die Flags wunderbar grafisch per Dropdown-Menü setzen, und seither ist da bei mir auch nichts mehr schiefgegangen. Braucht kein Setup, sondern läuft einfach so (installiertes und zur Windows-Version passendes WAIK natürlich vorausgesetzt):
https://www.autoitscript.com/site/autoit-tools/gimagex/
Viele Grüße
von
departure69
ich hab' mich mit den möglichen Parametern zum ImageX-Befehl auch schon vielfach erfolglos herumgequält. Bis ich dann endlich entdeckt hatte, daß ein freundlicher Mensch mal eine GUI dafür programmiert hat, zumindest für mich als Mausschubser-Admin ideal. Dort kann ich bspw. die Flags wunderbar grafisch per Dropdown-Menü setzen, und seither ist da bei mir auch nichts mehr schiefgegangen. Braucht kein Setup, sondern läuft einfach so (installiertes und zur Windows-Version passendes WAIK natürlich vorausgesetzt):
https://www.autoitscript.com/site/autoit-tools/gimagex/
Viele Grüße
von
departure69
Servus departure69,
Danke für den Tipp.
Hier gäbe es eine schöne Auflistung der EditionID's der OS und wie man diese mit dem Parameter /flags bei ImageX korrekt einpflegt:
http://technet.microsoft.com/de-at/library/cc749447(v=ws.10).aspx
Ich probiere aber mal das Tool GImageX und lasse die SKU einfach blank. Mal schauen, was dann passiert ...
Danke für den Tipp.
Hier gäbe es eine schöne Auflistung der EditionID's der OS und wie man diese mit dem Parameter /flags bei ImageX korrekt einpflegt:
http://technet.microsoft.com/de-at/library/cc749447(v=ws.10).aspx
Ich probiere aber mal das Tool GImageX und lasse die SKU einfach blank. Mal schauen, was dann passiert ...
Ich habe es nur mit Windows 8.1 Pro benutzt und da wurde natürlich beim Setup der Key abgefragt und die dazu passende Edition installiert. Kann also keine Erfahrungswerte für Server OS liefern.
Kurzes Update:
Die OS-Installation mit dem Image + integrierte Windows Updates funktioniert OHNE Unattend.xml, aber sobald man diese Datei mitverwendet, tritt das in der Threaderöffnung besagte Problem auf.
Was aber nach wie vor nicht nachvollziehbar ist, die OS-Installation funktioniert bei "nacktes" Original-Image von Installations-DVD OHNE Windows Updates aber dafür MIT Unattend.xml
Mittlerweile war auch ein Consultant von Microsoft vor Ort und wir haben im 4 Augen-Prinzip die Panther-Logs der beiden Fälle analysiert, jedoch bis jetzt noch ohne Erkenntnis zur Fehlerursache ...
Die OS-Installation mit dem Image + integrierte Windows Updates funktioniert OHNE Unattend.xml, aber sobald man diese Datei mitverwendet, tritt das in der Threaderöffnung besagte Problem auf.
Was aber nach wie vor nicht nachvollziehbar ist, die OS-Installation funktioniert bei "nacktes" Original-Image von Installations-DVD OHNE Windows Updates aber dafür MIT Unattend.xml
Mittlerweile war auch ein Consultant von Microsoft vor Ort und wir haben im 4 Augen-Prinzip die Panther-Logs der beiden Fälle analysiert, jedoch bis jetzt noch ohne Erkenntnis zur Fehlerursache ...
Hallo,
wir haben mittlerweile in Zusammenarbeit mit Microsoft und auch VMware versucht, das Problem zu analysieren und eingrenzen zu können.
Leider war es nicht möglich, einen Zusammenhang bei den getesteten Szenarien zu erkennen, das Problem scheint unlösbar zu sein und wird als "Phänomen" zu den Akten gelegt.
Danke für eure Hilfe, Gruß Markus
wir haben mittlerweile in Zusammenarbeit mit Microsoft und auch VMware versucht, das Problem zu analysieren und eingrenzen zu können.
Leider war es nicht möglich, einen Zusammenhang bei den getesteten Szenarien zu erkennen, das Problem scheint unlösbar zu sein und wird als "Phänomen" zu den Akten gelegt.
Danke für eure Hilfe, Gruß Markus
Hhmmm, nach Deinem vorletzten Post zu urteilen, macht die spezielle Kombination integrierte Updates + Deine unattend.xml Probleme.
Ohne integrierte Updates funktioniert es mit Deiner unattend.xml.
Ohne Deine unattend.xml funktioniert es mit integrierten Updates.
Soweit richtig?
Dann steht meines Erachtens in Deiner Antwortdatei etwas drin, was sich mit irgendeinem Update (tja. mit welchem, Nadel --> Heuhaufen?) beißt.
Wenn Du ganz viel Zeit hast, würde ich mit Zehnerblöcken von Updates testen, erstmal nur die ersten 10, wenn kein Fehler, die nächsten 10, dieses Spiel solange, bis der 10er-Block mit Updates auftaucht, wo es dann Probleme gibt. Und diese 10 dann einzeln auseinandernehmen. Wie gesagt, das verschlingt unendlich viel Zeit, könnte Dich aber auf das/die Update(s) bringen, das oder die hier Ärger bringt.
Wenn Du Glück hast, wird das (für Dich) fehlerhafte Update aber vielleicht schon an einem der nächsten Patchdays gegen ein neueres ausgetauscht (das passiert sowieso recht häufig, auch ohne Zusammenhang zu Deinem Problem) und Deine Prozedur funktioniert einfach wieder.
Ich würde die Prozedur einfach weiterhin einmal monatlich testen, irgendwann geht sie einfach wieder, und Du weißt gar nicht, warum (also welches Update jetzt schuld war).
Grüße
von
departure69
Ohne integrierte Updates funktioniert es mit Deiner unattend.xml.
Ohne Deine unattend.xml funktioniert es mit integrierten Updates.
Soweit richtig?
Dann steht meines Erachtens in Deiner Antwortdatei etwas drin, was sich mit irgendeinem Update (tja. mit welchem, Nadel --> Heuhaufen?) beißt.
Wenn Du ganz viel Zeit hast, würde ich mit Zehnerblöcken von Updates testen, erstmal nur die ersten 10, wenn kein Fehler, die nächsten 10, dieses Spiel solange, bis der 10er-Block mit Updates auftaucht, wo es dann Probleme gibt. Und diese 10 dann einzeln auseinandernehmen. Wie gesagt, das verschlingt unendlich viel Zeit, könnte Dich aber auf das/die Update(s) bringen, das oder die hier Ärger bringt.
Wenn Du Glück hast, wird das (für Dich) fehlerhafte Update aber vielleicht schon an einem der nächsten Patchdays gegen ein neueres ausgetauscht (das passiert sowieso recht häufig, auch ohne Zusammenhang zu Deinem Problem) und Deine Prozedur funktioniert einfach wieder.
Ich würde die Prozedur einfach weiterhin einmal monatlich testen, irgendwann geht sie einfach wieder, und Du weißt gar nicht, warum (also welches Update jetzt schuld war)
.Grüße
von
departure69
Die Analyse unseres Microsoft Consultant ergab einen kleinen Fehler in der Unattend.xml, welcher sich aber seiner Meinung nach eigentlich nicht auf die OS-Installation auswirken SOLLTE.
Nun stehen wir eben vor der Frage, warum die OS-Installation
- Original-Image + Unattend.xml funktioniert,
- modifziertes Image (integrierte Updates) OHNE Unattend.xml funktioniert
und
- modifziertes Image (integrierte Updates) + Unattend.xml NICHT funktioniert
!?
Er hat uns nun eine korrigierte Version der Unattend.xml zur Verfügung gestellt, welche wir nun adaptieren und testen werden. Vielleicht ist der Fehler nun dadurch ausgemerzt!?
Nun stehen wir eben vor der Frage, warum die OS-Installation
- Original-Image + Unattend.xml funktioniert,
- modifziertes Image (integrierte Updates) OHNE Unattend.xml funktioniert
und
- modifziertes Image (integrierte Updates) + Unattend.xml NICHT funktioniert
!?
Er hat uns nun eine korrigierte Version der Unattend.xml zur Verfügung gestellt, welche wir nun adaptieren und testen werden. Vielleicht ist der Fehler nun dadurch ausgemerzt!?
