Windows 10: Eventuell Probleme mit opsiclientd oder LoginBlocker?

[damien.leviet]

Hallo zusammen,

wir haben seit der Umstellung auf Windows 10 ein sehr nerviges Problem festgestellt, und zwar kommt es regelmäßig vor,
dass wenn unsere Kollegen etwas länger von ihren Laptops fernbleiben, nach ihrer Rückkehr und dem Drücken von STRG + ALT+ ENTF den "Ladekreisel" von Windows 10 angezeigt bekommen und das Gerät ab da auch nicht mehr weiter reagiert. Man muss das Gerät mit langen Drücken der POWER Taste ausschalten und neustarten, dann geht es wieder.

Wir haben schon zahlreiche Dinge ausprobiert, jedoch eines noch nicht: den OPSI Client Agent zu deinstallieren!
Beim Start des Computers erscheint ja kurz das Schloss von OPSI Login Blocker und verschwindet anschließend (ca. 5-10 Sekunden). Dabei sieht man ebenfalls den Ladekreisel und kann nichts machen.

Meine Frage:
Habt ihr dieses Problem in gleicher oder zumindest ähnlicher Art feststellen können?
Dank der Coronakrise und weitreichenden Einschränkungen kann ich momentan leider nicht in meinem Arbeitsbüro so oft vorstellig sein, um weitere Tests durchzuführen. Sofern wäre ich über euer Feedback sehr dankbar

Bleibt gesund und bis später,
Damien

[Jan.Schmidt]

Salve,

hast du mal [strg] [alt] [entf] erneut gedrückt?
Wenn nein - mach (später) mal

Zu deiner Frage:

Habt ihr dieses Problem in gleicher oder zumindest ähnlicher Art feststellen können?

kommt drauf an - wenn du damit meinst

* Rechner wird gestartet
* "kein schwein meldet sich an" (frei nach Max Raabe)
* und dann passiert das

dann ja - aber eher sehr selten

[damien.leviet]

Hallo nochmal,

es muss an OPSI liegen, denn mir ist jetzt bei ein paar Laptops aufgefallen, dass ich die Session Infos nicht abrufen kann.
Verbinde ich mich per Konsole (psexec) auf die Geräte und versuche, den OPSI Dienst neuzustarten (net stop opsiclientd && net start opsiclientd), dann hängt sich der Dienst weg:

Code: Alles auswählen

C:\Windows\system32>net stop opsiclientd && net start opsiclientd
opsiclientd wird beendet.......
opsiclientd konnte nicht beendet werden.

Der Dienst wird gerade gestartet oder beendet. Versuchen Sie es später erneut.

Vielleicht eine kleine Anmerkung zu unserer Konfiguration:

• Alle Geräte haben gui_startup deaktiviert
• Unsere Fest-PCs haben on_shutdown aktiviert
• Unsere Laptops haben die WAN Funktionalität freigeschaltet, also weder gui_startup noch on_shutdown

Ich vermute, dass wenn der Client keine Antwort vom Server erhält, dann dreht der sich unendlich im Kreis und reagiert nicht mehr (blockiert dann überdies den ganzen Rechner).

Es passiert auch nicht immer, jedoch häufig genug
@Jan.Schmidt: selbstverständlich. Es hängt sich weg, sodass man nur noch mittels lang gedrückter POWER-Taste neustarten kann

Gruß Damien

[damien.leviet]

Kurzes Update:

Wir haben mittlerweile den Opsi-Client-Agenten als Ursache für die längeren Ladezeiten ausmachen können.
Sowie der Client deinstalliert war, konnte der Kollege, der für mich getestet hat, wieder ohne Verzögerungen arbeiten.

Ich muss dazu sagen, dass noch Version 4.1.0.0-32 installiert war.
Mittlerweile ist ja Version 4.1.0.0-40 erschienen.

Ich habe ihm diese neue Version installiert und folgende Properties (für WAN/VPN) aktiviert:

Code: Alles auswählen

opsiclientd.event_gui_startup.active: false
opsiclientd.event_gui_startup{user_logged_in}.active: false
opsiclientd.event_net_connection.active: true
opsiclientd.event_timer.active: true

Selbstverständlich haben wir das Modul gekauft, sonst würde es gar nicht erst funktionieren.

Ich beobachte momentan mittels folgender Übersicht seine Events:
https://host.domain.de:4441/info.html

Logs habe ich nachgeschaut, konnte jedoch keine großen Unstimmigkeiten feststellen.
Einzig nachfolgender Auszug ist zumindest merkwürdig:

Code: Alles auswählen

[3] [Apr 09 10:33:09] [ product cache service         ] Failed to connect to config service 'https://opsi.mydomain.de:4447/rpc': timed out after 30 seconds   (OpsiService.pyo|106)
[3] [Apr 09 10:33:09] [ product cache service         ] Failed to cache products: Failed to connect to config service 'https://opsi.mydomain.de:4447/rpc': timed out after 30 seconds   (CacheService.pyo|856)
[3] [Apr 09 10:33:09] [ config cache service          ] Failed to connect to config service 'https://opsi.mydomain.de:4447/rpc': timed out after 30 seconds   (OpsiService.pyo|106)
[3] [Apr 09 10:33:09] [ config cache service          ] Errors occurred while syncing config from server: Failed to connect to config service 'https://opsi.mydomain.de:4447/rpc': timed out after 30 seconds   (CacheService.pyo|539)
[6] [Apr 09 10:42:24] [ event generator timer         ] Testing preconditions of configs: [<EventConfig: timer>]   (Events.pyo|403)
[6] [Apr 09 10:42:24] [ event generator timer         ] Firing event '<ocdlib.Events.TimerEvent object at 0x0753E8D0>'   (Events.pyo|443)
[6] [Apr 09 10:42:24] [ event generator timer         ] Event info:   (Events.pyo|444)
[6] [Apr 09 10:42:24] [ event generator timer         ] Starting FireEventThread for listeners: [<OpsiclientdNT61(Thread-1, started daemon 6896)>]   (Events.pyo|467)
[6] [Apr 09 11:23:11] [ event generator net_connection] Testing preconditions of configs: [<EventConfig: net_connection>]   (Events.pyo|403)
[6] [Apr 09 11:23:11] [ event generator net_connection] Firing event '<ocdlib.Events.CustomEvent object at 0x07599890>'   (Events.pyo|443)
[6] [Apr 09 11:23:11] [ event generator net_connection] Event info:   (Events.pyo|444)

Wieso ist so ein großes Loch zwischen 10:42:24 und 11:23:11?
Der event_timer hat ein Intervall von 600 Sekunden, ergo müsste doch zumindest das angezeigt werden?

Danke für eure Antworten.

Gruß,
Damien

[Jan.Schmidt]

Verbinde ich mich per Konsole (psexec) auf die Geräte und versuche, den OPSI Dienst neuzustarten (net stop opsiclientd && net start opsiclientd), dann hängt sich der Dienst weg:

Hmmmm dein Weg ist aber sehr - der Dennis aus Hürth bei Köln würde sowas wie leider nein leider garnicht dazu sagen.

Ist dir aufgefallen, das es zwei Opsidienste gibt?
Der eine ist der den du nicht über Dienste verbinden mit als Admin killst, sondern über Psexec.
Der andere ist der mit dem nichtsagenden Namenszusatz Guard - der sofort Alarm schlägt wenn der erstere Dienst abgrützen sollte.

Zuerst den Überwacher kicken - dann den Arbeiter - so wird ein Schuh draus.

Und wegen dem WAN (und dem pebkac da oben)
Ich hab (zu blond zu alt whatever) das WAN Modul nicht "auf die Schnelle mit studium rtfm" hoch & runter zum laufen gekriegt und werde das irgendwann mal mit den UIBlern zusammen im zuge eines (wie auch immer) machen.
Aber vielleicht brauchst du das ja nicht.

Gruß

[damien.leviet]

Verbinde ich mich per Konsole (psexec) auf die Geräte und versuche, den OPSI Dienst neuzustarten (net stop opsiclientd && net start opsiclientd), dann hängt sich der Dienst weg:

Hmmmm dein Weg ist aber sehr - der Dennis aus Hürth bei Köln würde sowas wie leider nein leider garnicht dazu sagen.

Ist dir aufgefallen, das es zwei Opsidienste gibt?
Der eine ist der den du nicht über Dienste verbinden mit als Admin killst, sondern über Psexec.
Der andere ist der mit dem nichtsagenden Namenszusatz Guard - der sofort Alarm schlägt wenn der erstere Dienst abgrützen sollte.

Zuerst den Überwacher kicken - dann den Arbeiter - so wird ein Schuh draus.

Und wegen dem WAN (und dem pebkac da oben)
Ich hab (zu blond zu alt whatever) das WAN Modul nicht "auf die Schnelle mit studium rtfm" hoch & runter zum laufen gekriegt und werde das irgendwann mal mit den UIBlern zusammen im zuge eines (wie auch immer) machen.
Aber vielleicht brauchst du das ja nicht.

Gruß

Ich kann mittlerweile bestätigen, dass unsere "Gedenkpausen" der Laptops mit dem OSPI Client Agent zusammenhingen.
Seit der Installation von Version 4.1.0.0-40 (vorher 4.1.0.0-32) ist das Problem verschwunden.
Das konnte mir meine Testperson mit seinem Laptop bestätigen; vorher hatte er quasi jeden Tag mindestens 2-3 Mal diese Aussetzer.

Wenn ich noch mehr darüber in Erfahrung bringen sollte, werde ich es hier posten.

Gruß,
Damien