das uns zur Verfügung stellen eines Geraetes im Rahmen eines Supportvertrags.
Ich habe darüber nachgedacht, den Rechner einzusenden. Allerdings steht das Rollout für Mittwoch auf dem Plan und bis dahin wäre der sicherlich nicht wieder hier (wie üblich arbeitet man unter Druck am besten und schiebt solche Rollouts bis zur letzten Sekunde vor sich her
)
Ich kläre das mit dem Kunden ab, ob er noch einige Zeit warten kann.
Nur noch mal zur Klarstellung: weder das bootimage, noch WinPE haben irgendwelche Aktien in der Installation von Treibern ins eigentliche Betriebssystem.
Ohne mich mit der Mechanik der Treiberverteilung unter Opsi befasst zu haben, muss ich diese Aussage in Frage stellen, aber erst einmal so hinnehmen. Schließlich werden die Treiber im UEFI-Modus korrekt eingebunden.
Die Vermutung war, dass die Treiber entweder per /InstallDrivers-Parameter der setup.exe oder drvload ins WinPE und/oder zusätzlich über Post-Scripts per PnPUtil oder DevCon eingebunden zu "erzwungen" installiert werden.
Erste Anlaufstelle wären für mich die Panther-Logs.
Auf die Idee bin ich nicht gekommen - aber erstmal einen Kaffee, dann gehe ich die Sache an. Vielen Dank hierfür.
2. Bootreihenfolge
Auch hier war meine Vermutung, dass die Änderung der Bootreihenfolge nach erfolgreichem Setup bereits durch Post-Scripts im Opsi oder gar den Opsi-Client-Dienst wieder "gerade gezogen" wird. Ein Flag á la "Force Pxe first" in der Client-Config könnte sich als nützlich erweisen.
Hierzu noch eine Frage, die sich praktisch in 15 Minuten beantworten ließe: Kann die Boot-Reihenfolge durch das Setup auch bei gesetztem Bios-Passwort verändert werden? Das wäre - MS-Hoheit hin oder her - eine gravierende Sicherheitslücke. SecureBoot soll deaktiviert bleiben.
Im Februar hat UIB (OPSI) ein neues Bootimage (08.02.2018, experimental) erstellt. Dort ist ein Intel-Grafiktreiber integriert speziell für UEFI integriert worden. Am besten mal im LAB-Netz mit einem Klon von der OPSI-VM experimentieren.
Ich kann nicht ganz folgen. Mit dem experimentellen BootImage klappt es ja. Was natürlich dafür spricht, dass eben doch das Linux-BootImage seine Finger bei der Treiberintegration m Spiel hat.
"Wir" haben zwar 7000 UEFI-Lizenzen gekauft (2000 + 5000), dennoch stellt der Einsatz von UEFI für uns aufgrund dieser Boot-Reihenfolgen-Drangsalierung durch MS noch immer eher die Ausnahme dar. Da müssen noch einige Kaffees die Kehle runtergehen, bevor wir uns genötigt sehen, eigene Pakete und Scripte zur Manipulation des Bios zu basteln - ich für meinen Teil bevorzuge native Lösungen, die nicht versehentlich durch das nächste Produkt-Update überschrieben werden
Nachtrag 12.03.2018:
Wie ich gerade von meinem Kollegen Schaefer erfahren habe, hat dieser die Problematik "Bootreihenfolge" (um die es hier ja primär garnicht ging) bereits mit Herrn Wolf besprochen und den Hinweis auf das Paket "opsi-uefi-netboot" bekommen. Damit ist mein letzter Satz obsolet
(Quelle:
https://download.uib.de/opsi4.0/product ... 0.5-3.opsi )
Ist halt die Problematik, wenn Themen sich vermischen.
ABER: Auch er hat die Erfahrung gemacht, dass HP-Rechner sogar auf dieses Paket nicht anspringen.