forum.opsi.org

Hallo zusammen,

wir haben eine funktionierende win10-x64-Installation. Bei 80% der Rechner (diverse unterschiedliche Modelle) läuft die ganz artig problemlos durch. Bei einigen wenigen bleibt sie aber hängen. Und zwar installiert sie Windows und steht dann in der Anmeldemaske.

Bei den funktionierenden Rechnern, soweit das eben sichtbar passiert, sehe ich ein AutoLogin mit dem lokalen Administrator, und sobald der angemeldet ist, beginnt die opsi-client-agent-Installation und alles Weitere geht seinen Weg.

Nehme ich jetzt bei den stehenbleibenden Rechnern den lokalen Administrator und melde den manuell an, passiert danach genau das Gleiche - der opsi-client-Agent wird installiert und alles geht seinen Weg.

Ich habe als installfiles den Inhalt des MediaCreationTool von Microsoft genommen, die 1511er Version. In der unattend.xml habe ich nur minimale Änderungen zur mit dem win10-x64-Paket mitgelieferten Version vorgenommen, bspw. die Firewall für Domain-Umgebung auf false gesetzt, Remote-Support auf false gesetzt - jedenfalls erstmal nichts, was hier in Zusammenhang zu stehen scheint. Das Admin-Konto und das AutoLogin steht wie im Ursprung. Ich habe auch den DomainJoin normalerweise in der unattend.xml drin, habe den aber testweise mal rausgenommen, weil ein anderer Thread darauf hingewiesen hat. Das hat aber nichts am Verhalten geändert - nur, dass der Client jetzt eben kein Domain-Mitglied ist, wenn er stehenbleibt. Der DomainJoin hat bislang auch nie Probleme gemacht. Den würde ich als Ursache mal ausschließen.

Auf einem stehenbleibenden Rechner liegt unter C:\windows\Panther\ die korrekte unattend.xml mit korrekt ersetzten Variablen.
Im Setupact.log habe ich leider nichts gefunden, was mir einen Hinweis gibt. Die kann ich gerne nochmal raussuchen und posten, wenn das hilfreich ist.

Meine Frage an dieser Stelle ist erstmal, wie kann das an dieser Stelle überhaupt zu einem Stillstand kommen? Wenn ich die unattend.xml richtig verstehe, müsste doch in der Registry unter Windows NT\winlogon ein AutoAdminLogon eingetragen werden, mit dem dann die Anmeldung beim ersten Boot durchgeführt wird, und dann die postinst-Skripte ausgeführt werden, oder? In der Registry eines stehenbleibenden Rechners steht nämlich das AutoAdminLogon auf 0 und es sind kein Username und kein Passwort gesetzt.
Warum läuft das bei 80% der Rechner ohne Probleme, aber bei einigen eben nicht?
In welchen Logs finde ich ggf. den entscheidenden Hinweis?

Liebe Grüße
Jens

Hallo Jens,

wir haben als das 1511 Build erschienen ist genau die selben Problemen gehabt. Aus diesem Grund wurde die unattend.xml für win-10 komplett neu erstellt. Anders war das nicht zu Handhaben. Da du mit einer angepassten unattend.xml arbeitest, solltest du mal deine unattend.xml aus custom wegsichern und die aus opsi/unattend.xml.template als unattend.xml in custum reinkopieren. Läuft damit die Installation durch?

Leider nein. Das habe ich gestern abend mal durchgespielt, es bleibt aber leider auch mit der als template gelieferten Version an der selben Stelle hängen.
Ich habe die unattend.xml aus der Paketversion win10-x64_4.0.6.1-3 als Basis genommen, da war die neue unattend.xml laut release notes ja schon drin. Jetzt habe ich auch aus der neuesten 4.0.6.2-3 die unattend.xml angesehen, die ist aber genau gleich.

Gab es irgendeine Erkenntnis bei Euch, an was es hier überhaupt scheitert?

Ok, unser Problem war gelöst mit der Neuerstellung der unattend.xml. Bei dir tritt das auch nicht immer auf. Deshalb würde ich das jetzt mal ausschliessen. Das Autologin wird ja gesetzt und danach wieder zurückgenommen. Sonst würde sich der Client immer automatisch einloggen. Als nächstes würde ich mal die postinst.log checken, liegt normalerweise in c:\tmp. Hast du so eine Log und wenn ja, was steht da drin? Wenn nicht, dann muss man seine Suche vor dem postinst noch mal fortsetzen.

Moin,

endlich komme ich wieder dazu, das Thema anzugehen. Leider bin ich kein Stück weitergekommen.

Ich habe mittlerweile festgestellt, dass das Problem scheinbar doch bei jedem System und jedes Mal auftritt. Mittlerweile habe ich ein Update auf die Version 4.0.7.1 gemacht (sowohl die opsi-serverkomponenten, als auch win10-x64), habe aber noch immer den gleichen Effekt (auch mit der mitgelieferten unattend.xml.template).

Bei einem dieser Rechner habe ich die Logdateien zu analysieren versucht.
Unter C:\ gibt es weder ein Verzeichnis tmp noch ein Verzeichnis opsi oder opsi.org. Demnach leider auch kein Postinst.log.
Also habe ich mal die logs aus C:\windows\panther geschnappt. Darunter gab es ein Verzeichnis UnattendGC ebenfalls mit einer setupact.log und setuperr.log. Ich habe darin nichts wirklich aussagekräftiges entdeckt, weiß aber zugegebenermaßen auch nicht genau, wonach ich suche!
Wonach müsste ich Ausschau halten?

Hallo,

wir haben gerade neue Versionen veröffentlicht. Bitte mal die neueste opsi-client-agent Version verwenden und noch mal testen. Weiterhin wäre die Frage, was Ihr für ein Windows 10 Medium einsetzt. Ist das ein Recoverymedium? Wenn ja, daran könnte aus liegen. Ich würde mal versuchen mit dem mediacreationtool eine neue Windows 10 Iso zu erstellen. Nur um sicher zu gehen, dass es nicht an euren Medien liegt.

Hmmm... wir haben die 1511er Version aus dem MediaCreationTool zugrunde liegen. Ich habe die auch auf einem Stick für manuelle Installation, aber da habe ich natürlich keinen Vergleich, ob sie automatisch laufen würde...

Ich habe die neue opsi-client-Agent-Version mal installiert, auch wenn ich mir davon noch nicht viel verspreche, weil er bis zur Installation des Agents ja bislang gar nicht gekommen ist. Damit teste ich nochmal.

Parallel habe ich gerade mal mit den 1607er Installfiles getestet und da läuft er durch. Wir können 1607 zwar noch nicht produktiv setzen, aber damit wird sich das Problem wohl automatisch lösen.

Ich habe eine Lösung!! und dabei ein paar neue Erkenntnisse gesammelt, die vielleicht auch für andere relevant und interessant sind:

Wir haben derzeit ein Rollout für einen bestimmten Gerätetyp mit Windows 10 Version 1607, der problemlos durchlief.
Kürzlich blieb das Windows-Setup plötzlich am Login hängen, obwohl es bislang immer durchgelaufen war. Sobald man dann das Administrator-Kennwort eingab, fragte das Setup, ob man ein Update direkt herunterladen und die 4GB in Kauf nehmen möchte. Klickte man auf "Jetzt nicht", blieb trotzdem der "Windows 10 Upgrade Assistant" auf dem Desktop zurück, die Installation lief dann durch.

Daraufhin habe ich massiv recherchiert und folgendes in Bezug auf die unattend.xml (im custom-Verzeichnis der Windows-Pakete zu finden) festgestellt:

1. wurde seit Windows 8.1 als deprecated erklärt und uib hat ihn artig aus den Paketen herausgenommen. Ich hatte ihn ursprünglich wieder hinzugefügt, weil ich während des Setups (damals Windows 10 1511) immer die Frage nach dem ProductKey bekommen hatte. Wir verwenden für die Installation den GenericKey für Windows10Pro, mit dem man Windows installieren, aber nicht aktivieren kann. Nach dem hinzufügen dieses Parameters lief die Installation anfangs durch. Eine Weile später blieben nach und nach einige, bald alle Geräte an der Anmeldemaske stehen.
Wir haben diesen Umstand dann erstmal als unlösbar hingenommen. Das unattend.xml.template hatte ich damals auch probiert, und die dann zusätzlich aufpoppende ProductKey-Maske wohl gar nicht mit dem nach wie vor nicht funktionierenden Autologin in Verbindung gebracht.
Da ich jetzt weiß, dass der Parameter ungültig ist, habe ich ihn nun wieder herausgenommen und lange recherchiert, warum ich nach dem ProductKey gefragt werde, obwohl er im "WindowsPE"-Pass unter Microsoft-windows-Setup eingetragen ist und akzeptiert wird.

2. Laut Microsoft-Doku wird im WindowsPE der ProductKey nur für die Installation verwendet und im Specialize für die spätere Aktivierung. Bei älteren Versionen von Windows stand auch: Wenn er im Specialize nicht enthalten ist, wird er auf der Willkommensseite immer abgefragt. In der aktuellen Version heißt es nur:

Wenn der Product Key nicht vor Out-Of-Box Experience (OOBE) angegeben wird, fordert OOBE den Endbenutzer zur Eingabe eines Product Keys auf. Wenn der Enbenutzer diesen Vorgang während OOBE überspringt, wird der Benutzer später an die Eingabe eines gültigen Product Keys erinnert.

Jedenfalls hatte SkipMachineOOBE scheinbar das ProductKey-Eingabefenster unterdrückt, aber auch das Setzen des AutoLogins (und anderer OOBE-Parameter?) verhindert, weswegen Windows dort stehen blieb.

Unsere 1607-Installation verwendet keinen Generic Key, sondern den mit dem jeweiligen Rechner mitgelieferten. Kaum hatte ich SkipMachineOOBE aus dieser unattend.xml rausgeworfen, lief diese Installation wieder unattended durch.
Unsere 1511er fragte aber weiter nach dem ProductKey und blieb danach hängen.
Im "Specialize"-Pass unter Microsoft-Windows-Shell-Setup habe ich dann den ProductKey über das Tag hinzugefügt. (war im windows7-unattend.xml-Template früher auch auskommentiert enthalten)
Nun läuft auch die 1511er-Installation durch.

Eine weitere Erkenntnis noch dazu:
3. Die Installationen blieben beide erst eine Weile nach problemloser Produktiver Nutzung am Login hängen. Ich schlussfolgere, dass zu dem Zeitpunkt die jeweils nächste Version von Windows 10 offiziell ausgerollt wurde (so ist es jetzt gerade bei 1607) und der SkipMachineOOBE Parameter auch dazu führte, dass "DynamicUpdates" bei der Installation aktiviert wurden. Das zeigt sich klar im ganz zu Anfang beschriebenen Verhalten mit der Frage nach einem Update (und war damals bei 1511 genauso).

Im WindowsPE-pass kann man den Parameter hinzufügen. Damit soll die Installation ohne Online-Quellen durchgeführt werden und der Upgrade-Assistant und auch die Abfrage nach aktuelleren Updates unterbunden werden. Das ist auch die Standardeinstellung, wenn der Parameter nicht angegeben wird! Auch ohne diesen Parameter laufen jetzt beide Windows Installationen (1511 und 1607) OHNE die Frage nach einem Update und OHNE den Windows 10 Upgrade Assistant durch.

Vielleicht kann jemand das mit dem Generic Key auch offiziell bestätigen? Meine Tests sprechen jedenfalls dafür.
Vielleicht sollte der o.g. ProductKey-Parameter auch offiziell in das template? Es könnte jemandem sehr sehr viel Arbeit ersparen! Es gab aber sicher auch einen Grund für das Herausnehmen...

@jensito

mmh, ziemlich viel Input aber wir haben hier in unseren automatisierten oder auich manuellen tests das genannte Problem

"win10-x64 bleibt sporadisch vor Installation des opsi-client-agent stehen"

definitiv gar nicht.

Fuer Anregungen fuers template nebst Begründung sind wir dankbar, am besten mittels diff an info<at>uib.de gegen das akuelle Gruss
Bardo Wolf