WINPE Partition wird nicht gelöscht

[mattiasmab]

Da PMs scheinbar ausgeschaltet sind leider der sehr offensichtliche wink - das Log besser schnell in seiner aktuellen Form löschen. Da sind einige Daten drin, die nicht drin sein sollten...

[Maikarl]

Ja so kann man das auch auf der Console sehen wenn man dem Client beim installieren zu guckt. In der unattend.xml ist so auch nix aussergewöhnliches zu finden. Hab sie mal angehangen.

unattend.xml

(13.66 KiB) 188-mal heruntergeladen

[Maikarl]

Das Bootimage Logfile habe ich gelöscht. Was meinst du mit PMs? Und wo kann denn die PMs eingeschalten.

[mattiasmab]

Was meinst du mit PMs? Und wo kann denn die PMs eingeschalten.

PrivateNachrichten - entschuldige. Das scheint global deaktiviert - einschalten somit wohl nicht möglich.

Ja so kann man das auch auf der Console sehen wenn man dem Client beim installieren zu guckt. In der unattend.xml ist so auch nix aussergewöhnliches zu finden. Hab sie mal angehangen.

Das und auch das ausgefüllte XML-File aus dem Log sieht ganz normal aus. Auch dort ist lediglich die Modifikation der DREI Partitionen im Hinblick auf die Änderung des Active-Flag von WinPE zu Windows selbst.

Ich kann mir nicht erklären, wo diese letzte Partition herkommen soll. Man sollte das schrittweise beobachten. Nach dem Bootimage (Linux) und VOR dem Start in das WinPE z.B. schauen, was dort für Partitionen sind. Dann nach der Installation von Windows - testweise ohne irgendwelche Pakete. Vielleicht wird ja auch irgendein BIOS-Recovery-Tool von HP/DELL/Fujitsu aktiv und schaltet das durchs UEFI dazwischen (kenne nicht, aber denen traue ich alles zu...). Vielleicht auch einmal testweise die Treiber weglassen (temporär den byAudit-Ordner für den Typ umbenennen.
Ich kann nur sagen, dass das Setup drei Partitionen laut log hat und beim Postinst dann vier vorhanden sind - allerdings mit voller größe der eigentlich letzten Partition (WinPE) was das eingestellt noch weniger nachvollziehbar macht.

Vielleicht noch abschließend - benutzt ihr das letzte Win10(-x64)-Paket von UIB oder modifiziert das und das hängt evtl. hinterher oder jemand hat evtl. bewusst Modifikationen vorgenommen?!
Ansonsten wäre ich aus der Ferne leider Ratlos woran das (noch) liegen könnte - sorry.

EDIT: Habt ihr vielleicht ein Skript in Postinst.d das die WinRE einrichtet und VOR dem Script des Pakets steht?
EDIT2: Vielleicht das einfach in einem der betroffenen Systeme prüfen, da folgende Befehle eine WinRE anzeigen müssten:

Code: Alles auswählen

# Wiederherstellungsumgebung prüfen
reagentc /info
# Prüfen was im Bootmanager von Windows eingetragen worden ist. Gibt es zum {current}-Eintrag einen Eintrag recoverysequence?
bcdedit /enum all

[Maikarl]

Hallo,

also ist das Standard win10-x64-captured Paket von UIB. Hab jetzt nochmal 2 Dinge ausprobiert und dabei ist mir folgendes aufgefallen. Habe den Rechner mal mit einem alternativen Medium über USB-Stick gebootet und mir die Partitionierung angeschaut einmal nachdem das Opsibootimage durchgelaufen ist und die Treiber und das WINPE kopiert und dann nach dem das Windows Setup im WINPE durchgelaufen ist. Dabei ist mir aufgefallen das zwischen der Windows Partition und der WINPE Partition ein freier Speicher von 1,95 GB ist. Keine Ahnung warum das so ist, aber scheinbar erstellt Windows 10 dann eine Wiederherstellungspartition. Habe jetzt nochmal ne Installation in Gang ohne Software nur mit Domjoin. Mal schauen was er dann macht. Das es an der Software liegt kann ich mir nicht vorstellen, da hier nur Standard Gedöns wie Acrobat Reader, Office, Vlc Player etc. installiert wird. Der Client ist auch nicht im UEFI Modus.

EDIT: Also Script ist keins hinterlegt. Wenn müsste es ja im Ordner custom\postinit.d liegen und setup_after_install ist auch leer beim Netboot Produkt

Gruß
Thomas

[mattiasmab]

das Standard win10-x64-captured Paket von UIB

Also ein per Sysprep erstelltes WIM, was dort installiert wird. Um das als Fehler auszuschließen, nutze doch mal das win10-x64 mit den original Installationsdaten.
Wir haben hier OPSI 4.2 seit ein paar Monaten im Einsatz und rollen gerade mehrere neue PC-Pools aus und haben dieses Problem zumindest nicht. Ihr nutzt laut Log aber auch eine LTSC (wir die normale). Zudem halt jetzt customized-Images. Alles in allem zwar aufwändig, aber mit dem nackten original-Windows anfangen, dann Treiber dazu und das gegen das andere setzen.
Die Paketinstallationen abzuschalten war eher eine Empfehlung bzgl. Geschwindigkeit. Da die ominöse WINRE-Partition beim Postinst vorhanden ist, ist das noch weit vor der Installation der Pakete, da durch ein Script im Postinst.d auch erst der opsi-client-agent eingerichtet wird.

Das wird schon

[Maikarl]

Hallo,

so Problem ist gelöst. Es lag nicht am Opsiserver oder am Upgrade auf 4.2, sondern an meinem Sysprep Image. Jetzt nach der Installation mit dem vorherigen Aufzeichnungsabbild ist wieder alles so wie es sein soll. Danke für Eure Hilfe!

Gruß
Thomas