[gelöst] Auffälligkeiten mit W11-24H2 + win11-x64_4.3.0.2-9.opsi

[wla]

Alle Tests mit aktuellem opsi-server-full-4.3.5, W11-24H2 + win11-x64_4.3.0.2-9.opsi / EFI Boot

• boot-Partition
  Auch wenn man sie anlegt (boot_partition_size>0), wird 24H2 sie nicht nutzen. Bei Aktivierung von Bitlocker (nach der fertigen Installation) verkleinert Windows c: und richtet zusätzlich eine Partition vom Typ winre ein.
  s.a. viewtopic.php?t=14297

• unattend.xml - zusätzliche Treiber
  Die zuständigen Treiber werden zwar nach c:\drv kopiert, aber nicht installiert.
  Sie werden aber installiert, wenn man (nach der fertigen Installation) im Gerätemanager, oben auf dem Computer, mit rechter Maustaste "Treiber hinzufügen" und den Ordner c:\drv angibt.

• unattend.xml - Syntax
  Mit dem mitgelieferten template habe ich ein Problem entdeckt.

  Code: Alles auswählen

  <component name="Microsoft-Windows-PnPCustomizationsWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <DriverPaths wcm:keyValue="1">
              <PathAndCredentials wcm:keyValue="1" wcm:action="add">
  	        <!--
  	        <Path wcm:keyValue="1">#@winpe_partition_letter*#:\drvpe</Path>
  	        -->
                  <Path wcm:keyValue="1">c:\drvpe</Path>
              </PathAndCredentials>
          </DriverPaths>
  </component>

  Mit der originalen, hier auskommentierten Variante bleibt die Installation hängen, der Rechner bleibt mit der cmd stehen, rebootet nicht.
  Setzt man c:\drvpe ein, läuft die Installation durch.

• opsinetmount.exe
  Bringt manchmal Fehler, macht aber nach einer Verzögerung weiter. Der Pfad stimmt - die Meldung ist irreführend!

  

  opsinetmount.gif (28.63 KiB) 2799 mal betrachtet

Ich hoffe die Infos sind nützlich für die Entwickler und sie geben Feedback.
Danke.

[m.radtke]

Guten Morgen,

erstmal vielen Dank fürs Teilen deiner Erkentnisse.
Feedback ist immer wichtig für uns.

Zu Deinen Punkten:

boot Partition
Die boot Partition wird im Grunde genommen benötigt um in einer Bitlocker Verschlüsselten Installation den Boot von eben dieser Partition zu beginnen. Irgendwo muss ja etwas nicht verschlüsseltes liegen. Seinerzeit wurde dies auf Kundenwunsch mit Windows Vista in opsi implementiert, da eben dieser Kunde Bitlocker verwenden wollte.
Im Legacy Modus werden auf eben dieser Bootpartition die nötigen bootdateien hinterlegt. Im UEFI Modus ist die Verwendung der Boot Partition im Grunde genommen obsolet, denn es gibt ja die EFI Partition auf der die Bootdateien liegen. Eine vorhandene Bootpartition wird im UEFI Modus nicht mit Boot relevanten Daten befüllt sofern eine Bitlocker Verschlüsselung vollzogen wird.
Der Parameter ist aus historischen Gründen noch vorhanden. Die Ganzen Windows Netboot Pakete basieren auf einem SetupSkript, welches Fallunterscheidungen (OLI, VHD, normal) macht. Windows 11 erlaubt es zwar nicht mehr im Legacy Modus zu laufen (offiziell) dennoch ist der Parameter aus Kompatibilitätsgründen noch drin. In Zukunft könnte man es so umbauen das keine Boot Partition angelegt wird wenn die Maschine zB im UEFI Modus läuft. Hierfür benötigt es schlicht weg Zeit.

unattend.xml - zusätzliche Treiber
Dieses Verhalten kann ich nicht beobachten. Ich habe testweise, in einer VM, nach dem Durchlauf durch das WinPE, der VM die Netzwerkkarte entzogen. Somit ist die VM durch den Specialize und OOBE Teil ohne Netz gelaufen mit dem Hintergrund zu Verhindern das irgendwelche Treiber durch Windows Updates installiert/aktualisiert werden. Am Ende hatte ich in der VM keine unbekannten bzw nicht durch Treiber versorgten Geräte.
Das Gleiche werden wir noch mit einer echten Maschine testen.

unattend.xml - Syntax
Auch dieses Verhalten haben wir in unseren Tests und Installationen nicht beobachten können.
Beim Booten wird die WinPE Partition als C gemountet, wir ändern das aber schon bevor die setup.exe startet in W. Wir mussten diese Änderung machen, da 24h2 viel anfälliger auf Ungereimtheiten in der unattend.xml reagiert als früher. Somit ist zum Zeitpunkt der Ausführung der setup.exe die C Partition entweder nicht mehr vorhanden, oder aber als System Partition angelegt auf der das drvpe Verzeichnis nicht existiert. Denn es existiert in dem Fall ja auf W.
Das man einfach in der CMD landet unter 24h2 habe ich aber durchaus beobachtet, dies lag aber immer an Secureboot. 24h2 spuckt wohl noch seltener Fehlermeldungen aus als vorherige Versionen.

opsinetmount.exe
Die Meldung ist unschön, das gebe ich zu.
Auch hier gibt es einen Grund für dieses Verhalten. Am Anfang wird versucht mit dem vom WinPE geladenen Treiber eine Verbindung zum Share herzustellen. Dies passiert an die 15 mal, es kann ja manchmal dauern bis die Netzwerkkarte sich initialisiert hat. Wenn diese 15 Versuche nicht klappen wird es mit den im Treiberverzeichnis, welche im Bootimage auf die WinPE Partition übertragern wurden. Diese Treiber werden durchiteriert, sofern mehrere scheinpar kompatible Treiber gefunden wurden. Im Normalfall geht die Installation dann mit der setup.exe weiter.

Ich hoffe meine Erläuterung hat Dir beim Verständnis der Installation weiter geholfen.

Grüße
Mathias

[wla]

Danke Matthias, für Deine ausführlichen und verständlichen Erläuterungen!

unattend.xml - Syntax
Ich habe dies mehrmals gemacht, nachvollziehbar und immer mit dem gleichen Ergebnis. Man sieht in meinem Auszug der unattend.xml die beiden Alternativen, sonst nichts geändert.
Meine Tests liefen in einer VM (ohne TPM, ohne secure boot).

Die anderen Punkte nehme ich an, wie von Dir beschrieben.

[m.radtke]

Moin,

mach mal bitte folgendes:

Wenn du wieder in der CMD bist, gib mal "notepad" ein. Notepad sollte sich öffnen. Dann kannst du mal gucken welche Laufwerksbuchstaben existieren. Mach davon mal ein Bild/Screenshot und poste es hier.

Auf welcher Basis wurde das von Dir verwendete WinPE gebaut?

Gruß
Mathias

[wla]

Das Ergebnis:

unattend-syntax.gif (23.88 KiB) 2622 mal betrachtet

Das PE ist mit dem aktuellen "Windows Assessment and Deployment Kit (Windows ADK)" und "Windows PE-Add-On für das ADK" gebaut.

Mein Doku für's bauen der PE:
Um ein WinPE mit Opsi zu erstellen, eine temporäre aktuelle VM mit aktuellem win11 installieren.
In der VM:

1. VMWare Tools installieren
2. Ordnerstruktur anlegen

   Code: Alles auswählen

       mkdir c:\OPSI c:\WIMFILE
       mkdir c:\OPSI\Downloads c:\OPSI\winpe_drv

3. "Windows Assessment and Deployment Kit (Windows ADK)" und "Windows PE-Add-On für das ADK" nach c:\OPSI\Downloads, downloaden und installieren
4. winpe-Treiber Download, Entpacken, Vorbereiten:
   DELL
   Download nach C:\OPSI\Downloads , entpacken, Ordner network, storage nach C:\OPSI\winpe_drv\DELL-[LABEL] kopieren
   VMWare
   Download nach C:\OPSI\Downloads , entpacken VMware-tools-[LABEL].exe /a , [ZIEL] auswählen, aus "[ZIEL]\VMware\VMware Tools\VMware\Drivers", Ordner pvsci, vmxnet3 nach C:\OPSI\winpe_drv\vmware-tools-[LABEL] kopieren, Unterordner mit alten Windows-Versionen löschen
   virtio
   Download nach C:\OPSI\Downloads , entpacken msiexec /a virtio-win-gt-[LABEL].msi , entpackt Treiber nach C:\Virtio-Win, Ordner network, vioscsi, viorng (darin alles ausser jeweiligem win11-Ordner löschen, im jeweiligen win11-Ordner den Unterordner ARM64 löschen, falls vorhanden), nach C:\OPSI\winpe_drv\virtio-[LABEL] kopieren
5. winpe erstellen:
   optional, mit zusätzlichen Treibern automatisch - durch befüllen des Ordners [OPSI-DEPOT]\opsi-winpe\drivers mit den vorbereiteten Treibern aus C:\OPSI\winpe_drv
   Opsi Packet "opsi-winpe" auf "once" setzen, mit "on demand" starten.
   Die Dateien liegen nach Ausführung des Packets unter "C:\winpe_amd64\media".
   
   optional, zusätzliche Treiber manuell:

   Code: Alles auswählen

       WIM-Image mounten: dism.exe /mount-wim /wimfile:C:\winpe_amd64\media\sources\boot.wim /index:1 /mountdir:c:\WIMFILE
       Kopieren der Treiber ins WIM Image: dism.exe /image:C:\WIMFILE /Add-Driver /driver:C:\Drivers /recurse
       ( Listing der integrierten Treiber: dism.exe /image:C:\WIMFILE /Get-Drivers )
       Speichern der Änderungen: dism.exe /unmount-image /MountDir:C:\WIMFILE /commit
   

   optional, wenn Property win11_hardware_check genutzt werden soll:

   Code: Alles auswählen

       dism /Mount-Image /ImageFile:"C:\WinPE_amd64\media\sources\boot.wim" /index:1 /MountDir:"c:\WIMFILE"
       dism /image:"c:\WIMFILE" /add-package /packagepath:"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-WMI.cab"
       dism /image:"c:\WIMFILE" /add-package /packagepath:"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-WMI_en-us.cab"
       dism /image:"c:\WIMFILE" /add-package /packagepath:"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-WMI_de-de.cab"
       dism /image:"c:\WIMFILE" /add-package /packagepath:"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\WinPE-SecureStartup.cab"
       dism /image:"c:\WIMFILE" /add-package /packagepath:"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\en-us\WinPE-SecureStartup_en-us.cab"
       dism /image:"c:\WIMFILE" /add-package /packagepath:"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\WinPE-SecureStartup_de-de.cab"
       dism /image:"c:\WIMFILE" /add-package /packagepath:"c:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\WinPE_OCs\de-de\lp.cab"
       dism /Unmount-Image /MountDir:"c:\WIMFILE" /commit
   

   "C:\winpe_amd64\media" nach "[opsi_depot_rw]\win11-x64\custom\winpe_dell_vmware_virtio_[DATUM]" kopieren,
   Link win11-x64/winpe nach custom/winpe_dell_vmware_virtio_[DATUM]

Aktuelle winpe enthalten bereits EFI-Unterstützung (Unterordner EFI), dann (unter Linux) einen Softlink winpe_efi auf winpe erzeugen.
Rechte auf Opsi-Server mit "opsi-setup --set-rights" setzen.

[m.radtke]

Hi

Ist in deinem Fall W:/drvpe mit Treibern befüllt?

Schau doch mal unter W:/Windows/Panther/setupact.log und setuperr.log vielleicht entdeckst du da etwas.

In seinem Fall kann die setup.exe ja keine Treiber von c:/drvpe installieren, da das Laufwerk gar nicht da ist. Ich vermute das einer der Treiber dort ein Problem macht und die setup.exe da aussteigt.

Gruß
Mathias

[wla]

Es gibt unter w: sowohl das Verzeichnis drv als auch drvpe. Darin befinden sich die VMWare-Treiber. Der pvscsi-Treiber ist in beiden Verzeichnissen der gleiche.
dir /s /b w:\drv\*inf w:\drvpe\*inf
w:\drv\1\vm3d.inf
w:\drv\2\pvscsi.inf
w:\drv\3\vmxnet3.inf
w:\drv\4\vmci.inf
w:\drvpe\2\pvscsi.inf

Unter W: gibts kein Windows-Verzeichnis, Du meintest vlt. X:\Windows\Panther\NewOs\Panther. Der Inhalt von setuperr.log w.u. Laufwerk O: ist [opsi_depot], hier gibt es kein $WINDOWS.~BT

Code: Alles auswählen

2024-11-05 14:14:24, Error                        CDiagnosticsHelper::PersistDiagnosticsData: Failed to persist diagnostics data.: Win32Exception: \\?\o:\$WINDOWS.~BT\Sources\Diagnostics: The system cannot find the path specified. [0x00000003] class UnBCL::DirectoryInfo *__cdecl UnBCL::Directory::CreateDir(const class UnBCL::String *)[gle=0x00000003]
2024-11-05 14:14:24, Error                 MOUPG  CSetupManager::GetWuIdFromRegistry(12357): Result = 0x80070002
2024-11-05 14:14:24, Error                 MOUPG  CDlpActionDriverInstallation::ExecuteDriverInstall(1062): Result = 0x80070103[gle=0x00000103]
2024-11-05 14:14:24, Error                 MOUPG  CDlpActionDriverInstallation::ExecuteUnattendDriverInstall(1393): Result = 0x80070103[gle=0x00000103]
2024-11-05 14:14:24, Error                 MOUPG  CDlpActionDriverInstallation::ExecuteUnattendDriver(1272): Result = 0x80070103[gle=0x00000103]
2024-11-05 14:14:24, Error                 MOUPG  CDlpActionDriverInstallation::ExecuteRoutine(284): Result = 0x80070103[gle=0x00000103]
2024-11-05 14:14:24, Error                 MOUPG  CDlpActionImpl<class CDlpErrorImpl<class CDlpObjectInternalImpl<class CUnknownImpl<class IDriverAction> > > >::Execute(503): Result = 0x80070103
2024-11-05 14:14:24, Error                 MOUPG  CDlpTask::ExecuteAction(3334): Result = 0x80070103
2024-11-05 14:14:24, Error                 MOUPG  CDlpTask::ExecuteActions(3487): Result = 0x80070103
2024-11-05 14:14:24, Error                 MOUPG  CDlpTask::Execute(1643): Result = 0x80070103
2024-11-05 14:14:24, Error                 MOUPG  CSetupManager::ExecuteTask(3116): Result = 0x80070103
2024-11-05 14:14:24, Error                 MOUPG  CSetupManager::ExecuteTask(3078): Result = 0x80070103
2024-11-05 14:14:24, Error                 MOUPG  CSetupManager::ExecuteInstallMode(1047): Result = 0x80070103
2024-11-05 14:14:24, Error                 MOUPG  CSetupManager::ExecuteDownlevelMode(609): Result = 0x80070103
2024-11-05 14:14:24, Error                 MOUPG  CSetupManager::GetDUSetupResults(8418): Result = 0x80070490
2024-11-05 14:14:25, Error                        CDiagnosticsHelper::PersistDiagnosticsData: Failed to persist diagnostics data.: Win32Exception: \\?\o:\$WINDOWS.~BT\Sources\Diagnostics: The system cannot find the path specified. [0x00000003] class UnBCL::DirectoryInfo *__cdecl UnBCL::Directory::CreateDir(const class UnBCL::String *)[gle=0x00000003]

[m.radtke]

Hi

die Treiberinstallation gibt die Fehlermeldung "0x80070103" aus.

Und am Ende im Log "system cannot find the drive specified"
Daher der Abbruch.
Wenn du c:/drvpe verwendest wird das Verzeichnis da nicht gefunden und so wohl umgangen.
So würde ich das Verhalten interpretieren.

Gruß
Mathias

[wla]

Stimmt, "0x80070103".
Microsoft sagt dazu: "The error message 0x80070103 will appear when a device attempts to install a driver that is already present."

Aber ist das ein Grund zum Abbruch
Sehr empfindlich das Ganze. Aber warum passiert dies?
Ich habe einerseits den (gleichen) Treiber über das Localboot-Produkt opsi-winpe direkt im winpe Image und auch im Netboot-Produkt win11-x64\drivers.
Sollte doch kein Problem sein ...

[wla]

Ich habe mal temporär win11-x64\drivers "deaktiviert" - dann läuft es durch.

Man kann somit eingrenzen: der pvscsi-Treiber ist sowohl unter w:\drv als auch unter w:\drvpe - genau dann stoppt die Installation nachvollziehbar mit
Fehlermeldung "0x80070103" (Microsoft: "The error message 0x80070103 will appear when a device attempts to install a driver that is already present."

Aber das kann doch nicht so gewollt sein?