Mir ist aufgefallen, dass beim Upgrade von Windows 10 mittels windows10-upgrade die Tastatur nie gesperrt wird. Gab es mit dieser Funktion Probleme? Wenn nicht, gibt es zwei Fehler im Skript.
- Sowohl im produktiven als auch debugging-Modus wird der Variablen $LockKeyboard$ false zugewiesen.
- Außerdem wird in den Teilen nach dem zweiten und dritten Bootvorgang das Keyboard explizit aktiviert.
Abschließend noch ein Verbesserungsvorschlag: Nach der Installation könnte noch in der Registry der Wert wiederhergestellt werden, der den zuletzt angemeldeten Nutzer auf dem Loginbildschirm anzeigt. Der Nutzer opsisetup wird zwar gelöscht und die Autologon-Einstellungen werden zurück gesetzt. Will sich ein Nutzer nach dem Upgrade anmelden, sieht er aber einerseits, dass ein opsisetup-Nutzer angemeldet war und muss andererseits erst den Benutzer wechseln. Das ist weder eine kritische, noch unbedingt notwendige Funktion, das Ergebnis nach dem Upgrade wäre damit aber schlicht schöner.
windows10-upgrade Fehler im Skript
Re: windows10-upgrade Fehler im Skript
Hi andré,
gut in den code geschaut und erwischt.
Wir haben das script abgeleitet vom opsi-template-with-admin.
Allerdings wird hier kein adminstrativer user benötigt unter dem das ausgeführt wird.
Vielmehr handelt sich es um einen normalen user der eingeloggt sein muß, der aber das script nicht ausführt.
Das script wird direkt vom opsiclientd mit 'system' Rechten gestartet.
(Das ist also so eine Art on_demand bei eingoggtem user).
Beim opsi-template-with-admin sperren wir die Tastatur da hier ein offener administrativer account läuft.
Darauf haben wir hier jetzt verzichtet da es 'nur' ein normaler user ist und der Vorteil das sollte doch ein Fehler kommen
darauf reagiert werden kann uns wichtiger schien.
Aber wir haben den code nicht aufgeräumt...
Besteht ein Bedarf die Tastatur (optional per property) zu sperren ?
Den zweiten Hinweis habe ich aufgegriffen und bin einen fix gerade am testen ......
gruss
d.oertel
gut in den code geschaut und erwischt.
Wir haben das script abgeleitet vom opsi-template-with-admin.
Allerdings wird hier kein adminstrativer user benötigt unter dem das ausgeführt wird.
Vielmehr handelt sich es um einen normalen user der eingeloggt sein muß, der aber das script nicht ausführt.
Das script wird direkt vom opsiclientd mit 'system' Rechten gestartet.
(Das ist also so eine Art on_demand bei eingoggtem user).
Beim opsi-template-with-admin sperren wir die Tastatur da hier ein offener administrativer account läuft.
Darauf haben wir hier jetzt verzichtet da es 'nur' ein normaler user ist und der Vorteil das sollte doch ein Fehler kommen
darauf reagiert werden kann uns wichtiger schien.
Aber wir haben den code nicht aufgeräumt...
Besteht ein Bedarf die Tastatur (optional per property) zu sperren ?
Den zweiten Hinweis habe ich aufgegriffen und bin einen fix gerade am testen ......
gruss
d.oertel
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
http://www.opsi.org
For productive opsi installations we recommend support contracts.
http://www.uib.de
http://www.opsi.org
Re: windows10-upgrade Fehler im Skript
Danke für die Erklärung.
Ja, das Sperren wäre für uns notwendig, wenn wir einmal damit beginnen wollen Computer zu upgraden, die bei den Nutzern während des Upgrades stehen bleiben sollen. Ein Property, mit dem ich die Sperre wahlweise ausmachen könnte, wäre ideal. Ich müsste mal testen, ob der Abbrechen-Button gedrückt werden kann, der auf dem Setup-Bildschirm zu sehen ist. Aber selbst wenn der ohne Funktion ist, wäre es nicht gewünscht, dass die Nutzer während des Updates am PC rumspielen dürfen.
Ja, das Sperren wäre für uns notwendig, wenn wir einmal damit beginnen wollen Computer zu upgraden, die bei den Nutzern während des Upgrades stehen bleiben sollen. Ein Property, mit dem ich die Sperre wahlweise ausmachen könnte, wäre ideal. Ich müsste mal testen, ob der Abbrechen-Button gedrückt werden kann, der auf dem Setup-Bildschirm zu sehen ist. Aber selbst wenn der ohne Funktion ist, wäre es nicht gewünscht, dass die Nutzer während des Updates am PC rumspielen dürfen.