Windows10-Upgrade Paket - angemeldeter User wird nicht erkannt

[Valentino-46]

Hallo geschätzte OPSI Community,

aktuell bin ich am Upgraden unserer Windows 10 Installationen von 1803 auf 1903. Das OPSI Paket Windows10-Upgrade leistet hier natürlich hervorragende Arbeit.

Ich habe allerdings noch einen Fehler, den ich einfach nicht wegbekomme.
Sobald der OPSI Setup User angelegt wurde und das System neustartet, fährt Windows hoch, der OpsiSetupUser meldet sich an.

Code: Alles auswählen

comment: now let the autologon work
comment: it will stop with a reboot

Danach startet die Abfrage, welcher User angemeldet ist.

Code: Alles auswählen

comment: Part after 3. Reboot
comment: we will do the stuff with logged on user

Die sub_wait_for_user wird nun 60x durchlaufen (entspricht etwa 120 Sekunden). Aktuell habe ich es bereits auf 300x erhöht um zu sehen, ob er einfach nur zeitlich nicht hinterherkommt.
Leider kein Erfolg!

Code: Alles auswählen

   ~~~~~~~ Start Sub ~~~~~~~  sub_wait_for_user
   If
   $LoggedInUser$ = ""   <<< result true
   "1" INT< $timeout_sec$   <<< result true
   ("1" INT< $timeout_sec$)   <<< result true
   ($LoggedInUser$ = "") and ("1" INT< $timeout_sec$)   <<< result true
 Then
   Set  $LoggedInUser$=GetLoggedInUser
     The value of the variable "$LoggedInUser$" is now: ""
 EndIf
   
   ~~~~~~~ End Sub   ~~~~~~~  sub_wait_for_user
   
   
   ~~~~~~~ Start Sub ~~~~~~~  sub_wait_for_user
   If
   $LoggedInUser$ = ""   <<< result true
   "2" INT< $timeout_sec$   <<< result true
   ("2" INT< $timeout_sec$)   <<< result true
   ($LoggedInUser$ = "") and ("2" INT< $timeout_sec$)   <<< result true
 Then
   Set  $LoggedInUser$=GetLoggedInUser
     The value of the variable "$LoggedInUser$" is now: ""
 EndIf
   
   ~~~~~~~ End Sub   ~~~~~~~  sub_wait_for_user

Er erkennt einfach keinen angemeldeten User. Er ist aber definitiv angemeldet.

Gibt es hier irgendwas zu beachten? Sobald ich on demand ausführe, macht er weiter...das steht ja so auch in der "Fehlermeldung"

Code: Alles auswählen

 comment: no user logged in setup will fail
 comment: we try to suspend the script
 comment: perhaps you have to retry with a user logged in and fire on_demand
 Error: no user logged in setup will fail
 set ActionProgress to: no user logged in setup will fail, perhaps you have to retry with a user logged in and fire on_demand

Danach funktioniert auch alles. Aber ich kann leider nicht jeden PC des gesamten Unternehmens on demand im richtigen Moment installieren
Ich wäre für jede Hilfe super dankbar!

Beste Grüße,
Valentino

[tobias]

Moin,

ich hab das gleiche Problem ... aber nicht auf meinen testmaschinen daher bin ich da auch etwas Ratlos.
Feuer ich dann nochmal per OnDemand auf den Client funktioniert es tatsählich

Gruß
Tobias

[Valentino-46]

Hi nochmal,

also bei uns sind es auch keine Testmaschinen.
Ich habe jetzt versucht das Script zu überlisten. Nachdem er den User nicht gefunden hat (Function waitforloggedonuser) habe ich in die Zeile danach einfach direkt ein

Code: Alles auswählen

set $GetLoggedInUser$="opsiSetupUser"

eingebaut. Sozusagen Ihm das gegeben, was auch wirklich im System sichtbar ist. Der User ist ja tatsächlich auch angemeldet.
Danach macht er auch direkt weiter mit dem Script und fängt an die installfiles zu kopieren.
Anschließend startet er die Installation...doch hier bleibt er nun ewig hängen...30-40 Minuten passiert nichts.

Es handelt sich ja um die sub_setup.opsiscript Datei welche aufgerufen wurd und diese bleibt in der "winbatch_upgrade /sysnative" einfach hängen.

Es funktioniert also tatsächlich auch nur, wenn das Event nochmal on_demand gefeuert wird.
Dann ist auch die Installation natürlich für den "OPSISetupUser" sichtbar und alles funktioniert auch.

Hmmm, Server ist auch auf aktuellem Stand.
Wobei ich zugeben muss keine Testing Pakete zu verwenden, da ich ja nur Probleme mit dem kleinen Hänger habe. Ansonsten installiert sich Windows 10 1903 auch ohne Testing Pakete wunderbar.

Hat noch jemand einen Rat?

Mit freundlichen Grüßen,
Valentino

[tobias]

Mhhh also ich kann mir das echt nicht erklären woran es liegt

Auf meinen TEST VMs Funktioniert es absolut zuverlässig und ohne Probleme....

• - Client ist auf dem gleichen OPSI Server (nicht auf unserem Testing)
  - Client hat Windows 10 1703 wie die produktiven Clients die ich umstellen muss auch
  - Alle Pakete sind Aktuell
  - Client ist am AD angemeldet und in gleicher OU... es greifen also die gleichen GPOs
  - Beide haben die gleiche Version des Virenscanners (Sophos)

Und wie man im Log gut sehen kann, schmeißt GetLoggedInUser einen leeren Wert raus obwohl der Benutzer angemeldet ist (was übrigens ein abrufen der "Session Info" über den Configed auch bestätigt)

Code: Alles auswählen

(838)     [7] [Okt 07 07:26:42:861] [windows10-upgrade]       "7" INT< $timeout_sec$   <<< result true
(839)     [7] [Okt 07 07:26:42:861] [windows10-upgrade]       ("7" INT< $timeout_sec$)   <<< result true
(840)     [6] [Okt 07 07:26:42:861] [windows10-upgrade]       ($LoggedInUser$ = "") and ("7" INT< $timeout_sec$)   <<< result true
(841)     [6] [Okt 07 07:26:42:861] [windows10-upgrade]     Then
(842)     [6] [Okt 07 07:26:44:862] [windows10-upgrade]       Set  $LoggedInUser$=GetLoggedInUser
(843)     [6] [Okt 07 07:26:44:862] [windows10-upgrade]         The value of the variable "$LoggedInUser$" is now: ""
(844)     [6] [Okt 07 07:26:44:862] [windows10-upgrade]     EndIf

[wolfbardo]

Kann das Problem so nicht nachvolliehen.

Welche opsi-winst Version wird verwendet?

Gruss
Bardo Wolf

[wolfbardo]

Kann das Problem so nicht nachvollziehen.

Welche opsi-winst Version wird verwendet?

Gruss
Bardo Wolf

[tobias]

Moin,

also bei mir ist es die Version 4.12.1.5-1

Es tritt nicht auf allen Clients auf, aber bei sehr vielen. Blöderweise immer wenn ich explizit drauf schaue passiert es nicht ...

Die Urpsprungs Windows 10 Version war Windows 10 Enterprise 1703

[wolfbardo]

Bitte mal testen, ob

http://download.uib.de/opsi4.1/experime ... .09-1.opsi

besser verwertbare Logs bringt.

Gruss
Bardo Wolf

[tobias]

Nur nochmal zur Info.

Bei mir klappt es nun problemlos.
Geholfen hat einmal das experimental Paket und zusätzlich das umstellen des ProductProperty "temp_dir_for_event_starter" von "Applog" auf "tmp".

Hintergrund: Bei älteren Clients haben nur admins zugriff auf den Ordner Applog, der opsisetupuser kann also nicht auf diesen Ordner zugreifen und daher scheitert das login script.

Daher hat es in meinen TestVMs immer geklappt, aber auf den alten 1703er Clients eben nicht


Danke @ Bardo Wolf für die Unterstützung

[Valentino-46]

Hallo zusammen,

seltsamerweise habe ich hierzu keine Mails zugestellt bekommen. Hab das Topic erst jetzt wieder gelesen.

Ich muss zugeben, dass ich das Thema komplett übergangen habe. Ich habe das vorhandene windows10-Upgrade Paket so modifiziert, dass ich gar keinen User mehr abfrage sondern einfach dem Autologon vertraue. Außerdem arbeite ich über RunOnce und eine ausgeschaltete UAC und installiere immer identisch, egal ob WAN Konfiguration oder nicht. Jetzt läuft mein Paket auch und ich bin erstmal zufrieden.

Vielen Dank aber für die Unterstützung! Das nächste Upgrade kommt wieder
Grüße,
Valentino