Zum Testen hab ich einfach mal kurz einen WSUS bemüht. Die Idee hinter dem ganzen sah wiedermal so aus:
Warum soll ich ein Tool öffnen, wenn ich doch eh das Monitoring offen habe.
Im MSDN findet man zum Glück einige Codebeispiele mit denen man an die WSUS Api rankommt. Sicher man kann auch direkt an den SQL-Server ran aber wer weiß in wieweit sich die Datenbank bei einem Update ändert.
Den Quelltext findet ihr im Anhang. Einfach mit dem Visual Studio Express Edition kompilieren und weiter gehts.
Wenn es auf dem Wsus Server ausgeführt wird, generiert es für jeden Client zwei Zeilen Output im Nagios.cmd format.
- System – WSUS Reporttime: Diese Zeile liefert das letzte Reportdatum des Clients (letzter Statusreport)
- System – WSUS Status: Hier erscheinen Infos über den Paketstatus (Needed: 15, Failed: 0, Installed: 117)
Ist die Reporttime älter als 14 Tage, so geht der Check „System – WSUS Reporttime“ auf Warning
Ist die Anzahl der benötigten Pakete > 0, geht „System – WSUS Status“ auf Warning. Existieren Pakete mit Failed Status wird der Check auf Critical gesetzt.
[1270848916] PROCESS_SERVICE_CHECK_RESULT;CLIENTNAME;System - WSUS Reporttime;0;LETZTES_REPORT_DATUM [1270848942] PROCESS_SERVICE_CHECK_RESULT;CLIENTNAME;System - WSUS Status;0;Needed: 0, Failed: 0, Installed: 0
Die Exe kann man einfach per Scheduled Task laufen lassen und dann eine Ausgabeumleitung in eine Textdatei machen. Diese Datei sollte dann am besten im inetpub liegen, da wir sie dann vom Nagios server per wget abholen können.
Auf dem Nagiosserver kann die Datei dann über ein cat Textfile >> /usr/local/nagios/var/rw/nagios.cmd in die External Command Queue eingereiht und verarbeitet werden.
Die Clients benötigen zwei zusätzliche passive Servicechecks, diese weisst man am besten über eine Hostvorlage „Windows Client“ oder „Windows Server“ zu.
- System – WSUS Status
- System – WSUS Reporttime