8
MDT, Windows 1809 und SplitWim
Hallo zusammen,
wir nutzen hier das MDT um Windows 10 + Software, Treiber, etc zu verteilen. Dabei auch USB-Sticks für Aussenstellen.
Bisher lief da auch immer sehr gut. Nun wollte ich aber die 1809 hinzufügen. Leider ist die install.wim von der ISO aus dem VLSC größer als 4GB (4,2GB)
Ist natürlich blöd für FAT32, was ich aber dank UEFI brauche...
Doku und Internet sagt, ich soll in der control\settings.xml einfach den Wert <SkipWimSplit>True</SkipWimSplit> auf False setzen.
Nun fängt der bei Update des Media-Ordners auch brav an mit der Meldung "Splitting input Wim to 4095 MB each", fällt aber sehr schnell auf die Schnauze mit folgender Meldung:
Die Datei ist aber genau dort und kann auch zugegriffen werden. Ohne SkipWimSplit läuft auch alles, nur halt "ungesplitted".
Von hand per "Dism /Split-Image" lässt sie sich auch brav splitten, aber das MDT schafft es nicht.
MDT ist die aktuelle Version 6.3.8456.1000, ADK+WIM ist 1809
Hat jemand da eine Idee?
Gruß
wir nutzen hier das MDT um Windows 10 + Software, Treiber, etc zu verteilen. Dabei auch USB-Sticks für Aussenstellen.
Bisher lief da auch immer sehr gut. Nun wollte ich aber die 1809 hinzufügen. Leider ist die install.wim von der ISO aus dem VLSC größer als 4GB (4,2GB)
Ist natürlich blöd für FAT32, was ich aber dank UEFI brauche...
Doku und Internet sagt, ich soll in der control\settings.xml einfach den Wert <SkipWimSplit>True</SkipWimSplit> auf False setzen.
Nun fängt der bei Update des Media-Ordners auch brav an mit der Meldung "Splitting input Wim to 4095 MB each", fällt aber sehr schnell auf die Schnauze mit folgender Meldung:
Starting MDT Media Update
Opened the media deployment share.
System.Management.Automation.CmdletInvocationException: Die Datei "D:\DeploymentShare\Operating Systems\1809\Sources\install.wim" konnte nicht gefunden werden. ---> System.IO.FileNotFoundException: Die Datei "D:\DeploymentShare\Operating Systems\1809\Sources\install.wim" konnte nicht gefunden werden.
bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
bei System.IO.FileInfo.get_Length()
bei Microsoft.BDD.PSSnapIn.GenerateMDTMedia.ProcessRecord()
bei System.Management.Automation.CommandProcessor.ProcessRecord()
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
bei Microsoft.BDD.Wizards.GenerateMediaProgress.WizardProcessing()
bei Microsoft.BDD.Wizards.WizardProgress.InitiateWizardProcessing()Die Datei ist aber genau dort und kann auch zugegriffen werden. Ohne SkipWimSplit läuft auch alles, nur halt "ungesplitted".
Von hand per "Dism /Split-Image" lässt sie sich auch brav splitten, aber das MDT schafft es nicht.
MDT ist die aktuelle Version 6.3.8456.1000, ADK+WIM ist 1809
Hat jemand da eine Idee?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 400489
Url: https://administrator.de/forum/mdt-windows-1809-und-splitwim-400489.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
ich bin mir jetzt selbst nicht sicher aber warum brauchst du FAT32 bei UEFI?
ich bin mir jetzt selbst nicht sicher aber warum brauchst du FAT32 bei UEFI?
Zitat von @wiesi200:
Hallo,
ich bin mir jetzt selbst nicht sicher aber warum brauchst du FAT32 bei UEFI?
das selbe habe ich mich auch gerade gefragt und es kann eigentlich nicht stimmen: https://www.thomas-krenn.com/de/wiki/Windows_UEFI_Boot-Stick_unter_Windo ...Hallo,
ich bin mir jetzt selbst nicht sicher aber warum brauchst du FAT32 bei UEFI?
wenn man die Thomas Krenn Seite liest, stellt sich folgendes heraus
mit Rufus, wird auf dem screenshot "NTFS" gewählt
bei diskpart weiter unten wird "FAT32" gewählt mit dem Hinweis auf <4GB.
Die Lösung scheint diese zu sein:
https://github.com/pbatard/uefi-ntfs
Damit kann man mit Rufus erstellten images auch bei UEFI systemen von NTFS booten.
Bitte korrigiert mich wenn ich falsch liege.
(spannendes Thema mal wieder)
ps: benutze städig Rufus, aber das ist mir auch noch nicht aufgefallen bzw keine Gedanken gemacht
mit Rufus, wird auf dem screenshot "NTFS" gewählt
bei diskpart weiter unten wird "FAT32" gewählt mit dem Hinweis auf <4GB.
Die Lösung scheint diese zu sein:
https://github.com/pbatard/uefi-ntfs
Damit kann man mit Rufus erstellten images auch bei UEFI systemen von NTFS booten.
Bitte korrigiert mich wenn ich falsch liege.
(spannendes Thema mal wieder)
ps: benutze städig Rufus, aber das ist mir auch noch nicht aufgefallen bzw keine Gedanken gemacht
Hallo,
alles was ich dazu gefunden habe ist, dass per UEFI-Boot die Sticks FAT32 haben müssen.
z.B.
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sp ...
"USB keys formatted as FAT32. FAT32 is required to boot many modern (UEFI-based) PCs, but has a maximum file size of 4GB."
oder
https://unsortiertes.de/2016/uefi-boot-vom-usb-stick-funktioniert-nicht- ...
"Bei UEFI funktioniert das anders, da gibt es keinen Bootsektor mehr, sondern das UEFI sucht sich die Dateien direkt auf der Platte zusammen. Heißt natürlich, dass das Dateisystem von UEFI auch unterstützt werden muss. Der UEFI-Standard schreibt vor, dass FAT(12,16,32) unterstützt werden muss, alles andere (exFAT, NTFS, ext2, HFS+) kann unterstützt werden, wird aber meistens nicht. Ergo sollte man eine FAT32-Partition haben, die auf jeden Fall gelesen werden kann, und dort entweder die zu bootenden Dateien draufpacken oder zumindest einen NTFS-Treiber (wie es Rufus tut). Der NTFS-Treiber von Rufus ist aber nicht signiert, ergo funktioniert Secure Boot nicht (mehr)."
alles was ich dazu gefunden habe ist, dass per UEFI-Boot die Sticks FAT32 haben müssen.
z.B.
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sp ...
"USB keys formatted as FAT32. FAT32 is required to boot many modern (UEFI-based) PCs, but has a maximum file size of 4GB."
oder
https://unsortiertes.de/2016/uefi-boot-vom-usb-stick-funktioniert-nicht- ...
"Bei UEFI funktioniert das anders, da gibt es keinen Bootsektor mehr, sondern das UEFI sucht sich die Dateien direkt auf der Platte zusammen. Heißt natürlich, dass das Dateisystem von UEFI auch unterstützt werden muss. Der UEFI-Standard schreibt vor, dass FAT(12,16,32) unterstützt werden muss, alles andere (exFAT, NTFS, ext2, HFS+) kann unterstützt werden, wird aber meistens nicht. Ergo sollte man eine FAT32-Partition haben, die auf jeden Fall gelesen werden kann, und dort entweder die zu bootenden Dateien draufpacken oder zumindest einen NTFS-Treiber (wie es Rufus tut). Der NTFS-Treiber von Rufus ist aber nicht signiert, ergo funktioniert Secure Boot nicht (mehr)."
ne ISO "brennen" ist leider schon eine Wissenschaft für sich :D
Hallo,
So wie ich das jetzt gelesen habe, liefert Rufus einen NTFS-Treiber für UEFI mit. Damit geht es dann solange Secureboot aus ist, da dieser nicht signiert ist.
ok, wäre ein Workaround: Den Stick mit Rufus zu erstellen und während der Installation Secureboot auszuschalten...
Klärt trotzdem nicht die Frage, warum es im MDT zu dem genannten Fehler kommt.
So wie ich das jetzt gelesen habe, liefert Rufus einen NTFS-Treiber für UEFI mit. Damit geht es dann solange Secureboot aus ist, da dieser nicht signiert ist.
ok, wäre ein Workaround: Den Stick mit Rufus zu erstellen und während der Installation Secureboot auszuschalten...
Klärt trotzdem nicht die Frage, warum es im MDT zu dem genannten Fehler kommt.
Naja, wir bauen da eine durchgescriptete Installation mit der ganzen Anwendersoftware, Treiber für verschiedene Geräte, etc.
Ist mittlerweile etwas zu groß für ne DVD.
Und selbst wenn, welche Standard-Büro PCs haben heute denn noch DVD-Laufwerke? Unsere fast nicht mehr. Und ein USB-DVD-Laufwerk ist unhandlicher als ein USB-Stick.
Bisher war das auch alles kein Problem, da die install.wim < 4GB war.
Wenn Du die benötigte Edition extrahierst, kommen ca. 3,8 GB raus.
Grüße
Richard
Grüße
Richard
