16
New-WindowsImage schlägt fehl
Moin,
ich bin gerade dabei mich mit den PowerShell äquivalenten CMDlets von dism.exe zu beschäftigen.
Mein Ziel ist es, automatisch nach dem Volumen-Namen, eine Partition in eine wim-datei zu packen. Das ganze läuft in Windows PE.
Mein verwendeter Code:
Mein Problem ist nun, dass das speichern erst anfängt und kurz vor Ende mit dem Fehler "Datei ist nicht vorhanden" abbricht.
Wenn ich dann an den vorher festgelegten Speicherort schaue, ist die Datei wirklich nicht vorhanden. Was mich jetzt daran wundert ist, dass ich erwarten würde, dass der Vorgang am Anfang abbricht und nicht erst nach mehrere Minuten wenn der Fortschrittsbalken bereits 100% anzeigt.
Was könnte das Problem sein? Ein schreibgeschützter Datenträger ist es nicht, das hatte ich bereits getestet.
Viele Grüße
ich bin gerade dabei mich mit den PowerShell äquivalenten CMDlets von dism.exe zu beschäftigen.
Mein Ziel ist es, automatisch nach dem Volumen-Namen, eine Partition in eine wim-datei zu packen. Das ganze läuft in Windows PE.
Mein verwendeter Code:
$CAPTURE = Get-Volume -FileSystemLabel "OS" | % DriveLetter
$IMAGE_PATH = X:\IMAGES\Image.wim
New-WindowsImage -ImagePath $IMAGE_PATH -CapturePath $CAPTURE -CompressionType max -Name "OS" -verfiy Mein Problem ist nun, dass das speichern erst anfängt und kurz vor Ende mit dem Fehler "Datei ist nicht vorhanden" abbricht.
Wenn ich dann an den vorher festgelegten Speicherort schaue, ist die Datei wirklich nicht vorhanden. Was mich jetzt daran wundert ist, dass ich erwarten würde, dass der Vorgang am Anfang abbricht und nicht erst nach mehrere Minuten wenn der Fortschrittsbalken bereits 100% anzeigt.
Was könnte das Problem sein? Ein schreibgeschützter Datenträger ist es nicht, das hatte ich bereits getestet.
Viele Grüße
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: 54045659899
Url: https://administrator.de/contentid/54045659899
Printed on: April 27, 2024 at 06:04 o'clock
16 Comments
Latest comment
Meine Idee dazu:
$CAPTURE = (Get-Volume -FileSystemLabel "OS").DriveLetter
$IMAGE_PATH = "X:\IMAGES\Image.wim"
New-WindowsImage -ImagePath $IMAGE_PATH -CapturePath $CAPTURE -CompressionType max -Name "OS" -Verify 
Danke für die Idee, das würde ja in die Richtung gehen, dass Driveletter eventuell nicht korrekt ermittelt wird. Lasse ich mir das Ergebnis ausgeben funktioniert es wie gewünscht. Sporadisch funktioniert es auch, aber leider nicht zuverlässig. Die logfiles sind leider auch nicht sehr aufschlussreich.
Hallo,
Hast du denn mal verglichen wo es ging und wo es nicht ging was der unterschied ist? Vielleicht sind deine Log Dateien aber nur für dich zu gebrauchen
Und du weisst aber sicherlich auch das Laufwerksbuchstaben nur für das jeweilige laufende OS gelten. Selbst für Benutzer aufm gleichen System muss C: nicht zwingend das gleiche sein (was aber meistens so ist). Und ein C: in Windows XP muss nicht auch C: in Win 11 sein. In Linux ist es nicht immer sda1.
Gruß,
Peter
Hast du denn mal verglichen wo es ging und wo es nicht ging was der unterschied ist? Vielleicht sind deine Log Dateien aber nur für dich zu gebrauchen
Und du weisst aber sicherlich auch das Laufwerksbuchstaben nur für das jeweilige laufende OS gelten. Selbst für Benutzer aufm gleichen System muss C: nicht zwingend das gleiche sein (was aber meistens so ist). Und ein C: in Windows XP muss nicht auch C: in Win 11 sein. In Linux ist es nicht immer sda1.Gruß,
Peter
Das ist Recht einfach zu beantworten. Habe ich das Skript ein zweites Mal ausgeführt, war die Wahrscheinlichkeit gross das es erfolgreich war. Auf dem gleichen System.
Das mit den Laufwerksbuchstaben ist mir bekannt, daher mein Ansatz über den eindeutig zugewiesenen Volumen-Namen zu gehen und dadurch den aktuell verwendeten Laufwerksbuchstaben zu ermitteln.
Bezüglich der Logfiles: Deren Inhalt beschränkt sich leider auf Ausgaben wie die folgende: [1234.5678]
Das war jetzt nur ein Beispiel, davon sind aber einige Dutzend im Logfile zu finden ohne das etwas anders drin steht. Selbst wenn ich auf WarningInfo manuell umstellen.
Gruß
Das mit den Laufwerksbuchstaben ist mir bekannt, daher mein Ansatz über den eindeutig zugewiesenen Volumen-Namen zu gehen und dadurch den aktuell verwendeten Laufwerksbuchstaben zu ermitteln.
Bezüglich der Logfiles: Deren Inhalt beschränkt sich leider auf Ausgaben wie die folgende: [1234.5678]
Das war jetzt nur ein Beispiel, davon sind aber einige Dutzend im Logfile zu finden ohne das etwas anders drin steht. Selbst wenn ich auf WarningInfo manuell umstellen.
Gruß
X:\IMAGES\Image.wim
Das Image auf dem Scratch-Space abzulegen ist nicht sonderlich intelligent, der ist begrenzt und läuft dann natürlich über weil das Image dafür zu groß ist, deswegen läuft das dann auch in Fehler und ist hinterher auch keine Datei vorhanden , wie auch, Speichern kann der nicht in die Luft 😉.https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/w ...
WinPE reserves memory on the X: drive to unpack the WinPE files, plus additional temporary file storage, known as scratch space, that can be used by your applications. By default, this is 512MB for PCs with more than 1GB of RAM, otherwise the default is 32MB. Valid values are 32, 64, 128, 256, or 512.
1
Hast du dir den Befehl New-WindowsImage schon mal genauer angeschaut?
Es werden midestens 2 Argumente erwartet.
A) Das Argument -CapturePath. Erwartet einen vollständigen DriveLetter (bsp: C:\)
B) Das Argument -Name. Erwartet die Bezeichnung des Drive (Bsp: OS)
Bei mir liefert dein Code "C".
Ändere deinen Code auf:
Get-Help -Full New-WindowsImageEs werden midestens 2 Argumente erwartet.
A) Das Argument -CapturePath. Erwartet einen vollständigen DriveLetter (bsp: C:\)
B) Das Argument -Name. Erwartet die Bezeichnung des Drive (Bsp: OS)
Bei mir liefert dein Code "C".
$CAPTURE = Get-Volume -FileSystemLabel "Windows" | % DriveLetter Ändere deinen Code auf:
$CAPTURE = Get-Volume -FileSystemLabel "OS";
$IMAGE_PATH = "C:\IMAGES\test.wim";
#Naming-Test:
$cp__ = "$($CAPTURE.DriveLetter):\"
$n__ = $CAPTURE.FileSystemLabel
New-WindowsImage -ImagePath $IMAGE_PATH -CapturePath $cp__ -Name $n__ -Verify -CompressionType maxDas Image auf dem Scratch-Space abzulegen ist nicht sonderlich intelligent, der ist begrenzt und läuft dann natürlich über weil das Image dafür zu groß ist, deswegen läuft das dann auch in Fehler und ist hinterher auch keine Datei vorhanden , wie auch, Speichern kann der nicht in die Luft 😉.
Ups, da ist mir bei der Beschreibung etwas durcheinander geraten. Ich speichere natürlich nicht in X:\ sondern auf dem USB-Laufwerk, von dem mein WindowsPE bootet. Dieses Laufwerk hole ich mir ebenfalls, wie die internen Laufwerke auch.
Habe ich
Es werden midestens 2 Argumente erwartet.
A) Das Argument -CapturePath. Erwartet einen vollständigen DriveLetter (bsp: C:\)
B) Das Argument -Name. Erwartet die Bezeichnung des Drive (Bsp: OS)
Bei mir liefert dein Code "C".
A) Das Argument -CapturePath. Erwartet einen vollständigen DriveLetter (bsp: C:\)
B) Das Argument -Name. Erwartet die Bezeichnung des Drive (Bsp: OS)
Bei mir liefert dein Code "C".
$CAPTURE = Get-Volume -FileSystemLabel "Windows" | % DriveLetter Stimmt, das habe ich auch gemacht. Den Capture-Pfad hole ich mir automatisiert da er sich unter Umständen ändern kann. Den Parameter -Name gebe ich gesondert an (vorletzter Parameter in meinem Code), er wird nicht automatisch erzeugt. Zudem würde es doch zu einer Fehlermeldung kommen, wenn der Parameter -Name nicht vorhanden wäre.
New-WindowsImage -ImagePath $IMAGE_PATH -CapturePath $CAPTURE -CompressionType max -Name "OS" -Verify Ich werde dein Beispiel einmal testen, eventuell ist die automatische Zuordnung besser.
Das Problem schein der Parameter -Verify zu sein. Ohne diesen läuft das Skript reproduzierbar durch.
Leider habe ich nicht gefunden, wo MS die temporär erstellte Datei zum verify erstellt. Wird sie im RAM oder auf X:\ erstellt, ist natürlich kein Speicherplatz zur Verfügung.
Leider habe ich nicht gefunden, wo MS die temporär erstellte Datei zum verify erstellt. Wird sie im RAM oder auf X:\ erstellt, ist natürlich kein Speicherplatz zur Verfügung.
Zitat von @grmg2010:
Das Problem schein der Parameter -Verify zu sein. Ohne diesen läuft das Skript reproduzierbar durch.
Leider habe ich nicht gefunden, wo MS die temporär erstellte Datei zum verify erstellt. Wird sie im RAM oder auf X:\ erstellt, ist natürlich kein Speicherplatz zur Verfügung.
Das Problem schein der Parameter -Verify zu sein. Ohne diesen läuft das Skript reproduzierbar durch.
Leider habe ich nicht gefunden, wo MS die temporär erstellte Datei zum verify erstellt. Wird sie im RAM oder auf X:\ erstellt, ist natürlich kein Speicherplatz zur Verfügung.
-ScratchDirectory Parameter angeben
Specifies a temporary directory that will be used when extracting files for use during servicing. The directory must exist locally. If not specified, the \Windows\%Temp% directory will be used, with a subdirectory name of a randomly generated hexadecimal value for each run of DISM. Items in the scratch directory are deleted after each operation. You should not use a network share location as a scratch directory to expand a package (.cab or .msu file) for installation. The directory used for extracting files for temporary usage during servicing should be a local directory.
Oder bei deinem genutzten PE den Scratchspace schon im Vorfeld erhöhen:
WinPE Scratch-Speicherplatz mit DISM vergrößern
Ok, das heißt also, die Datei wird versucht in X:\ zu speichern, was natürlich nicht funktioniert. Dann lege ich den temporären Pfad manuell fest.
Gehört zwar nicht zu meiner Ursprungsfrage aber gehört noch in die selbe Richtung. Ich möchte einige Dateien und Ordner ausschließen. Grundsätzlich kein Problem, allerdings habe ich eine recht große Datei, die ohne Dateiendung ist.
Gibt es eine Möglichkeit, solche Dateien auch der Ausnahmenliste hinzuzufügen? Die folgenden Versuche haben nicht funktioniert:
Gibt es eine Möglichkeit, solche Dateien auch der Ausnahmenliste hinzuzufügen? Die folgenden Versuche haben nicht funktioniert:
[ExclusionList]
\path\file_wo_ext <- Wird nicht funktionieren, da kein Verzeichnis
\path\file_wo_ext*
\path\file_wo_ext*.*
Ist wohl ein Bug des PS-CMDlets, mit dism direkt klappt es
Why do these configuration file exclusions work with DISM /Capture-Image but not the New-WindowsImage cmdlet?
Why do these configuration file exclusions work with DISM /Capture-Image but not the New-WindowsImage cmdlet?
Leider in meinem Fall nicht, ich hatte es auch mit dism ausprobiert. Den Bug hatte ich bereits gefunden, kann ihn aber wie beschrieben umgehen. Andere Ordner in der Exclude-Liste funktionieren mit New-WindowsImage. Lediglich die Datei ohne Endung wird nicht ausgelassen.
Dann lösche sie vor dem Capture, oder verschiebe sie vorher wo anders hin (z.B. in einen Ordner der eh schon exkludiert wird oder auf ein anderes Laufwerk) und schiebe sie nach dem Capture wieder an ihren Ursprungsort wenn sie in der Quelle bleiben muss.
Verschieben wäre wahrscheinlich die einfachste Lösung in diesem Fall. Da sie kein Gigabyte groß ist, sollte das kein Speicherplatz oder Zeitproblem sein. Ein bereits exkludierten Ordner gibt es auf dem selben Laufwerk bereits.
Vielen Dank an alle, die zur Lösungsfindung beigetragen haben.
Viele Grüße
Viele Grüße