immer mal wieder haben wir bei manchen Rechner ein Problem mit dem Windows_Updates Plugin.
Dieses mal finde ich es besonders interessant. Im Gegensatz zu sonst scheint der Agent das Ergebnis ermitteln zu können.
Auf dem Windows 10 Rechner liefert ein manuelles Ausführen von „check_mk_agent.exe test“ folgendes Ergebnis:
<<<windows_updates:cached(1574245265,14400)>>>
0 0 0
Alles ok also. Keine verfügbaren Updates. Wenn man aber auf dem Server „check_mk -d rechnername“ ausführt, dann erhält man folgendes:
<<<windows_updates:cached(1574230897,14400)>>>
x x x
There was an error getting update information. Maybe Windows update is not activated. Error Number: -2145107924
Aus den 3 Nullen werden X. Aber nur bei dem Client. Bei einem anderen liefert der Server wirklich „0 0 0“.
Die Cache-Datei des Client auf dem Server unter tmp/check_mk/cache/ hab ich schon gelöscht. Beim Client unter Windows hab ich noch nicht rausgefunden, wo sie liegt.
wenn es manuell funktioniert und als “Local System” Service nicht dann schaut das so ähnlich aus wie früher die Einstellung Windows Updates nur manuell ermitteln lassen.
Die Optionen von früher gibt es nicht mehr in der Form in der Registry dafür gibt es unzählige Methoden per GPO diese Einstellungen anzupassen.
Könnte es sein, dass hier ein GPO Problem der Grund ist?
Früher musste erlaubt sein, dass der Rechner selbst nach Updates suchen darf und dies nicht erst manuell getriggert werden muss.
Sobald diese manuelle Einstellung erfolgt war keine Abfrage mehr per Script im Agent möglich.
Gruß
Andreas
···
Am Mi., 20. Nov. 2019 um 11:27 Uhr schrieb Wolfgang Ketterer Ketterer@neutron.de:
Hallo,
immer mal wieder haben wir bei manchen Rechner ein Problem mit dem Windows_Updates Plugin.
Dieses mal finde ich es besonders interessant. Im Gegensatz zu sonst scheint der Agent das Ergebnis ermitteln zu können.
Auf dem Windows 10 Rechner liefert ein manuelles Ausführen von „check_mk_agent.exe test“ folgendes Ergebnis:
<<<windows_updates:cached(1574245265,14400)>>>
0 0 0
Alles ok also. Keine verfügbaren Updates. Wenn man aber auf dem Server „check_mk -d rechnername“ ausführt, dann erhält man folgendes:
<<<windows_updates:cached(1574230897,14400)>>>
x x x
There was an error getting update information. Maybe Windows update is not activated. Error Number: -2145107924
Aus den 3 Nullen werden X. Aber nur bei dem Client. Bei einem anderen liefert der Server wirklich „0 0 0“.
Die Cache-Datei des Client auf dem Server unter tmp/check_mk/cache/ hab ich schon gelöscht. Beim Client unter Windows hab ich noch nicht rausgefunden, wo sie liegt.
Könnte es sein, dass hier ein GPO Problem der Grund ist?
Hm, wir haben zwar eine GPO welche den Updateservice der Clients auf den internen WSUS umbiegt. Aber erstens wüsste ich nicht welche Einstellung
hier relevant sein könnte und zweitens gilt die GPO ja für alle Clients. Das Problem haben aber derzeit nur 2 Rechner und einer davon auch nur sporadisch. Selbst bei dem Anderen funktioniert es manchmal.
Weiß jemand wo der Cache auf dem Client liegt bzw. wie man ihn löschen kann? Vielleicht steht da ja aus irgendeinem Grund Unsinn drin.
Hab auch schon überlegt, temporär auf das Caching zu verzichten und den Test jedes mal auszuführen. Aber das dauert halt.
···
Hallo Wolfgang,
wenn es manuell funktioniert und als “Local System” Service nicht dann schaut das so ähnlich aus wie früher die Einstellung Windows Updates nur manuell ermitteln lassen.
Die Optionen von früher gibt es nicht mehr in der Form in der Registry dafür gibt es unzählige Methoden per GPO diese Einstellungen anzupassen.
Könnte es sein, dass hier ein GPO Problem der Grund ist?
Früher musste erlaubt sein, dass der Rechner selbst nach Updates suchen darf und dies nicht erst manuell getriggert werden muss.
Sobald diese manuelle Einstellung erfolgt war keine Abfrage mehr per Script im Agent möglich.
Gruß
Andreas
Am Mi., 20. Nov. 2019 um 11:27 Uhr schrieb Wolfgang Ketterer Ketterer@neutron.de:
Hallo,
immer mal wieder haben wir bei manchen Rechner ein Problem mit dem Windows_Updates Plugin.
Dieses mal finde ich es besonders interessant. Im Gegensatz zu sonst scheint der Agent das Ergebnis ermitteln zu können.
Auf dem Windows 10 Rechner liefert ein manuelles Ausführen von „check_mk_agent.exe test“ folgendes Ergebnis:
<<<windows_updates:cached(1574245265,14400)>>>
0 0 0
Alles ok also. Keine verfügbaren Updates. Wenn man aber auf dem Server „check_mk -d rechnername“ ausführt, dann erhält man folgendes:
<<<windows_updates:cached(1574230897,14400)>>>
x x x
There was an error getting update information. Maybe Windows update is not activated. Error Number: -2145107924
Aus den 3 Nullen werden X. Aber nur bei dem Client. Bei einem anderen liefert der Server wirklich „0 0 0“.
Die Cache-Datei des Client auf dem Server unter tmp/check_mk/cache/ hab ich schon gelöscht. Beim Client unter Windows hab ich noch nicht rausgefunden, wo sie liegt.
der Agent selbst hält seinen Cache nur im Ram - restart des Service und Cache ist weg.
Du kannst auf den betroffenen Clients mal probieren den Widows Update Status zu bereinigen.
Gruß
Andreas
···
Am Fr., 22. Nov. 2019 um 10:22 Uhr schrieb Wolfgang Ketterer Ketterer@neutron.de:
Hallo Andreas,
Könnte es sein, dass hier ein GPO Problem der Grund ist?
Hm, wir haben zwar eine GPO welche den Updateservice der Clients auf den internen WSUS umbiegt. Aber erstens wüsste ich nicht welche Einstellung
hier relevant sein könnte und zweitens gilt die GPO ja für alle Clients. Das Problem haben aber derzeit nur 2 Rechner und einer davon auch nur sporadisch. Selbst bei dem Anderen funktioniert es manchmal.
Weiß jemand wo der Cache auf dem Client liegt bzw. wie man ihn löschen kann? Vielleicht steht da ja aus irgendeinem Grund Unsinn drin.
Hab auch schon überlegt, temporär auf das Caching zu verzichten und den Test jedes mal auszuführen. Aber das dauert halt.
wenn es manuell funktioniert und als “Local System” Service nicht dann schaut das so ähnlich aus wie früher die Einstellung Windows Updates nur manuell ermitteln lassen.
Die Optionen von früher gibt es nicht mehr in der Form in der Registry dafür gibt es unzählige Methoden per GPO diese Einstellungen anzupassen.
Könnte es sein, dass hier ein GPO Problem der Grund ist?
Früher musste erlaubt sein, dass der Rechner selbst nach Updates suchen darf und dies nicht erst manuell getriggert werden muss.
Sobald diese manuelle Einstellung erfolgt war keine Abfrage mehr per Script im Agent möglich.
Gruß
Andreas
Am Mi., 20. Nov. 2019 um 11:27 Uhr schrieb Wolfgang Ketterer Ketterer@neutron.de:
Hallo,
immer mal wieder haben wir bei manchen Rechner ein Problem mit dem Windows_Updates Plugin.
Dieses mal finde ich es besonders interessant. Im Gegensatz zu sonst scheint der Agent das Ergebnis ermitteln zu können.
Auf dem Windows 10 Rechner liefert ein manuelles Ausführen von „check_mk_agent.exe test“ folgendes Ergebnis:
<<<windows_updates:cached(1574245265,14400)>>>
0 0 0
Alles ok also. Keine verfügbaren Updates. Wenn man aber auf dem Server „check_mk -d rechnername“ ausführt, dann erhält man folgendes:
<<<windows_updates:cached(1574230897,14400)>>>
x x x
There was an error getting update information. Maybe Windows update is not activated. Error Number: -2145107924
Aus den 3 Nullen werden X. Aber nur bei dem Client. Bei einem anderen liefert der Server wirklich „0 0 0“.
Die Cache-Datei des Client auf dem Server unter tmp/check_mk/cache/ hab ich schon gelöscht. Beim Client unter Windows hab ich noch nicht rausgefunden, wo sie liegt.
der Agent selbst hält seinen Cache nur im Ram - restart des Service und Cache ist weg.
Du kannst auf den betroffenen Clients mal probieren den Widows Update Status zu bereinigen.
Gruß
Andreas
Am Fr., 22. Nov. 2019 um 10:22 Uhr schrieb Wolfgang Ketterer Ketterer@neutron.de:
Hallo Andreas,
Könnte es sein, dass hier ein GPO Problem der Grund ist?
Hm, wir haben zwar eine GPO welche den Updateservice der Clients auf den internen WSUS umbiegt. Aber erstens wüsste
ich nicht welche Einstellung hier relevant sein könnte und zweitens gilt die GPO ja für alle Clients. Das Problem haben aber derzeit nur 2 Rechner und einer davon auch nur sporadisch. Selbst bei dem Anderen funktioniert es manchmal.
Weiß jemand wo der Cache auf dem Client liegt bzw. wie man ihn löschen kann? Vielleicht steht da ja aus irgendeinem
Grund Unsinn drin.
Hab auch schon überlegt, temporär auf das Caching zu verzichten und den Test jedes mal auszuführen. Aber das dauert
halt.
wenn es manuell funktioniert und als “Local System” Service nicht dann schaut das so ähnlich aus wie früher die Einstellung Windows Updates nur manuell ermitteln lassen.
Die Optionen von früher gibt es nicht mehr in der Form in der Registry dafür gibt es unzählige Methoden per GPO diese Einstellungen anzupassen.
Könnte es sein, dass hier ein GPO Problem der Grund ist?
Früher musste erlaubt sein, dass der Rechner selbst nach Updates suchen darf und dies nicht erst manuell getriggert werden muss.
Sobald diese manuelle Einstellung erfolgt war keine Abfrage mehr per Script im Agent möglich.
Gruß
Andreas
Am Mi., 20. Nov. 2019 um 11:27 Uhr schrieb Wolfgang Ketterer Ketterer@neutron.de:
Hallo,
immer mal wieder haben wir bei manchen Rechner ein Problem mit dem Windows_Updates Plugin.
Dieses mal finde ich es besonders interessant. Im Gegensatz zu sonst scheint der Agent das Ergebnis ermitteln zu können.
Auf dem Windows 10 Rechner liefert ein manuelles Ausführen von „check_mk_agent.exe test“ folgendes Ergebnis:
<<<windows_updates:cached(1574245265,14400)>>>
0 0 0
Alles ok also. Keine verfügbaren Updates. Wenn man aber auf dem Server „check_mk -d rechnername“ ausführt, dann erhält man folgendes:
<<<windows_updates:cached(1574230897,14400)>>>
x x x
There was an error getting update information. Maybe Windows update is not activated. Error Number: -2145107924
Aus den 3 Nullen werden X. Aber nur bei dem Client. Bei einem anderen liefert der Server wirklich „0 0 0“.
Die Cache-Datei des Client auf dem Server unter tmp/check_mk/cache/ hab ich schon gelöscht. Beim Client unter Windows hab ich noch nicht rausgefunden, wo sie liegt.
