forum.opsi.org

Moin,

ich mache mal einen neuen Thread auf, obwohl es zu dem Thema windows10-upgrade schon welche gibt, wird einfach zu unübersichtlich,...

Ich habe mir dri Tstmaschinen vorbereitet:

2x Windows 10 1903, 1x W10 1809

Eine 1903 habe ich im Bestand, da habe ich vorher nur einen Snapshot gemacht, die anderen zwei Maschinen habe ich in Virtualbox neu aufgesetzt.
Danach habe ich das windows10-upgrade Pakt neu eingespielt, weil ich vorher schon damit rumgespielt hatte und eine möglichst saubere Umgebung haben wollte.

Danach habe ich die Files aus einer Win 10 1909 ISO extrahiert und in den Depotordner installfiles kopiert. Die Rechte auf die Files habe ich angepasst.

Jetzt habe ich den 1903er Masschinen das Produkt zum Setup gestellt und als einzige Änderungen das Passwort entsprechend unseren Richtlinien gesetzt und als Zielversion die 1909 ausgewählt. Vorerst hatte ich die 1809 ausgelassen.

Das Script lief on demand an, steht aber seit Gestern 17:00 Uhr auf "Preparing windows10-upgrade install step 1" und "Files_copy_event_starter finished"
Augenscheinlich passiert auf den Rechnern nichts mehr,...

Wie wäre der beste Weg, das Problem zu Untersuchen? In welche logs sollte ich schauen? Auf dem Client?

Grüße

Gregor

Moin,

auf welches Directory ist das Property "temp_dir_for_eventstarter" eingestellt?

Besonders bei älteren Clients sollte man hier tmp nutzen, da das default eingestellte Verzeichnis nicht für den opsisetupuser beschreibbar ist.

Verstehe ich es richtig, das Nichtmal der automatische reboot läuft?

Die logs vom opsi-script wären dabei dann hilfreich.


Gruß
Tobias

Hmm, beim durchsuchen des logs bin ich auf folgenden Eintrag gestoßen:

Code: Alles auswählen

[6] [Mrz 04 17:09:05:692] [windows10-upgrade] Set  $OpsiAdminPass$ = GetConfidentialProductProperty("temp_user_password","nt123")

Das ist nicht das Passwort, welches ich eigentlich gesetzt habe, sondern eines der Vordefinierten.
Setze ich das Property falsch? Ich mache das Property aus, gebe mein neues Passwort ein, dieses ist auch hervorgehoben, damit sollte es doch genommen werden?

Wobei im der Registry ist dann aber das von mir gesetzt,...

Tschuldigung, das war natürlich Quatsch,... da steht nur das Standardpasswort, habe ich falsch gedeutet,...

Hmm, ganz setlsam. nachdem ich gefühlt nur die Option quiet auf false geändert habe, läuft die Aktion durch,...

Der Rechner ist in den Neustart gegangen und die Installation läuft,...
Ich versuche das mal zu reproduzieren.

Man soll doch nie zwei Sachen gleichzeitig ändern,...

Es war doch das Passwort, was zu dem Verhalten geführt hat. Obwohl das temporäre Passwort unseren Richtlinien entsprochen hat, klappte damit scheinbar etwas nicht. Mit einem Alternativen PW läuft das Upgrade durch.

Allerdings ist es schon seltsam, das das an dieser Stelle passiert und auch keine Fehlermeldung produziert. Evtl. kann man da in einer zukünftigen Version des Scripts darauf Rücksicht nehmen,...

Grüße

Gregor

Moin,

ja da gibts ein paar Fallen, einmal die PW Richtlinie und das Passwort darf auch nicht zu lang sein...
Ist es zu lang, bleibt er einfach hängen (WINST bleibt offen) da das setzen des Passworts eine Nutzerinteraktion erfordert (die man nicht sieht) und dann beendet sich der Prozess nie.

Zweiteres könnte bzw. sollte man aber abfangen.