NSClient++ und darüber hinaus

nsclient-logoFür viele verschiedene Anwendungsgebiete bringt NSClient++ schon Funktionen mit, mit Hilfe derer man direkt und ohne Probleme Dinge wie Festplattenauslastung, CPU, Memory, Services und Logs abfragen kann.
Heute soll es einmal um die Themen gehen, die der NSClient nicht “out of the box” beherrscht.  Vor allem im Bereich der Client Überwachung gibt es hier noch ungenutztes Potential:

1.) Security Center

Mit Hilfe von WMI ist es auf einfache Weise möglich auf Windows Clients ab Vista zu überprüfen wie der Antivirus Status ist. Hierfür gibt es einen namespace “root\SecurityCenter2” mit der Klasse AntiVirusProduct. Hier kann man den Schlüssel ProductState überprüfen. Die Interpretation dieses Wertes ist nun leider nicht durchgängig Dokumentiert und sollte gegen das eigene Antivirus Produkt nochmal gegen geprüft werden.
Folgende Artikel können hierbei hilfreich sein:

2.) Windows Updates

Hierfür gibt es ein Powershell Plugin, dass einem beantwortet ob Updates anstehen oder ein reboot seiner Durchführung harrt. Da es mit dem Original Plugin von Jules ein paar bekannte Performance Probleme gibt empfehle ich hier die verbesserte Version von redbranch[Jonny]

3.) GPO – Gruppenrichtlinien

Bei den Gruppenrichtlinien handelt es sich um ein Server/Client basiertes System zur Verteilung von Windows Konfigurationsobjekten. Auf dem Client sollte man daher überprüfen, ob der Service zur Umsetzung dieser Konfigurationsanweisungen überhaupt läuft. Das lässt sich bequem mit dem NSClient++ erreichen indem man den Service “gpsvc” überprüft. Ob wirklich alle Richtlinien umgesetzt wurden kann man am besten auf dem Server überprüfen. Dazu im nächsten Teil der Serie mehr.

WMI reparieren

Sollte es einmal Probleme mit dem Windows Management Intrumentarium geben und man weiß nicht wie dieses zu reparieren ist, sollte man sich mal das Diagnose- und Repair-Tool von Microsoft hierfür anschauen.
 
Im nächsten Teil dieser Serie geht es um Advanced Windows Server Monitoring. Insbesondere wird es hierbei um GPOs und Windows Updates aus der Sicht der Servers gehen.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Microsoft Sharepoint Monitoring

Diese Woche habe ich mich mal wieder etwas in der Windows Welt herumgetrieben und einiges zum Thema Sharepoint Monitoring herausgefunden.
Da Sharepoint normalerweise in etwas größeren Firmen eingesetzt wird, und dann in der Regel auch entsprechend viele Mitarbeiter darauf zugreifen, ist der normale Windows Admin dazu angehalten eine wie auch immer topologisch aufgebaute Sharepoint Farm einzurichten. Diese kann aus mehreren Sharepointservern und einem MSSQL-Cluster im Hintergrund aufgebaut werden, aber auch andere Konstrukte und Topologien sind möglich.
Da man als Monitoring Guy aber nicht immer den vollen Einblick in die Planungen/Umsetzugen der Windowsabteilung hat möchte ich euch hier ein Plugin vorstellen, dass einem das Leben vereinfachen kann.
Das Plugin überwacht einem die komplette Sharepoint Farm mit einem einzigen check,
und das beste: Man muss nichts dafür wissen. Man muss sich nicht überlegen welche Komponenten man überwacht und auch nicht, welche Maschinen zu dem Konstrukt gehören. Soweit so gut:
Das Plugin bedient sich des “Sharepoint Health Analyzer”, welcher ab Sharepoint 2010 zur Verfügung steht. Dieser bringt schon einen Schwung an Checks mit, die sich allerdings noch im Nachgang mit der nötigen Expertise durch den Windows Admin erweitern lassen.
Das ganze wird eingebunden in ein ganz kurzes powershellscript, welches sich dann über nsclient++ aufrufen lässt.
Et voilà, c’est tout.
PS: Möchte man auch noch das powershellscript nicht selber schreiben kann man sich hier bedienen. Das Plugin könnte zwar noch ein paar Verbesserungen vertragen (–help usw.) Aber grundsätzlich tut es was es soll.
 
Bildquelle: http://i.technet.microsoft.com/hh973397.sharepoint.png

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Weekly Snap: DavMail & Lightning, Powershell & jQuery

weekly snap3 – 7 June started the month by beginning the OSMC 2013 countdown alongside tips for developers using Powershell and jQuery-AOP and one for sys admins.
Eva started her countdown to the OSMC 2013 with Bernd’s opening speech from 2012.
Matthias then introduced aspect-oriented programming using jQuery-AOP as Christopf triumphed over Powershell to find the right syntax to write to Array.
Finally Blerim discovered DavMail and Lighting his solution to integrating the Microsoft Exchange Server calendar into Thunderbird.

Letzte Ausfahrt PowersHell

Nachdem ich mich diese Woche mal wieder etwas mit einem meiner “Lieblingsthemen” beschäftigt habe möchte ich euch die neuesten Erkenntnisse natürlich nicht vorenthalten.
Also . . . Was bringt dir dieser Blogpost?
– Zeitersparnis beim Austüfteln der richtigen Powershell Syntax. Das war’s. Mehr nicht.
Reicht aber auch. Ich hätte mich gefreut wenn ich das so irgendwo gelesen hätte.
Kurze Erklärung: Ich war dabei ein Plugin zu schreiben, dass WMI-Tabellen abfragt, diese Auswertet und ein Ergebnis MIT Performancedaten an Icinga übergibt. Dazu schreibe ich verschiedene Dinge in ein Array und gebe sie am Ende des Plugins aus. An und für sich nicht schwer. Aber wie macht man es mit Powershell?
1.) Deklariere das Array RICHTIG, sonst geht’s nicht:
$perf_list = new-object 'System.Collections.Generic.List[string]'
2.) Schreibe die Daten hinein. Als erstes eine pipe, die die Perfdaten einleitet.
if ($perf) {$perf_list.add(@("`|"))} -> Pipe Zeichen ausgeben ist nicht einfach . . .
3.) Als nächstes dann die Performancedaten selber. Es geht hier um 3 Festplatten, denen jeweil drei Werte zugeordnet sind. Freier Platz, Warn- und kritischer Schwellwert. Die Ausgabe sollte dann so aussehen:
icinga@monitor0815:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.67.21 -p 5666 -c check_stuff -a “scripts\testps.ps1 -diskwarn 40 -diskcrit 30 -perf”
OK: |’DiskFree_Y:’=3025MB;1227.2;920.4 ‘DiskFree_X:’=3006MB;1227.2;920.4 ‘DiskFree_Q:’=467MB;203.2;152.4

4.) Und wird folgendermaßen korrekt ins Array geschrieben.
if ($perf) {$perf_list.add(@("DiskFree_"+$i.path+"="+$i.FreeSpace+"MB`;"+($i.TotalSize*$diskWarn/100)+"`;"+($i.TotalSize*$diskCrit/100)+" "))}
5.) Und so am Ende ausgegeben.
foreach ($i in $perf_list) {
#write-host "l"
write-host -NoNewLine $i
}

Doch leider hat es ziemlich lange gedauert bis ich zu diesem Ergebnis gekommen bin und mich vermutlich 5 Jahre meines lebens und 153 graue Haare gekostet.
Also spielen wir mal eine kurze Runde Fehlersuche: Wo ist der Unterschied zu oben ?
So hat’s nicht geklappt
icinga@monitor0815:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.67.21 -p 5666 -c check_stuff -a “scripts\testps.ps1 -diskwarn 40 -diskcrit 30 -perf”
OK: |’DiskFree’=0 ‘Y:’=3025MB;1227.2;920.4 ‘DiskFree’=0 ‘X:’=3006MB;1227.2;920.4 ‘DiskFree’=0 ‘Q:’=467MB;203.2;152.4

if ($perf) {$perf_list.add(@("DiskFree "+$i.path+"="+$i.FreeSpace+"MB`;"+($i.TotalSize*$diskWarn/100)+"`;"+($i.TotalSize*$diskCrit/100)+" "))}
Und so auch nicht . . .
icinga@monitor0815:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.67.21 -p 5666 -c check_stuff -a “scripts\testps.ps1 -diskwarn 40 -diskcrit 30 -perf”
OK: |’DiskFree_Y:’=3025MB;1227.2;920.4;1227.2;920.4

if ($perf) {$perf_list.add(@("DiskFree_"+$i.path+"="+$i.FreeSpace+"MB`;"+($i.TotalSize*$diskWarn/100)+"`;"+($i.TotalSize*$diskCrit/100)))}
Und so erst recht nciht . . . .
icinga@monitor0815:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.67.21 -p 5666 -c check_stuff -a “scripts\testps.ps1 -diskwarn 40 -diskcrit 30 -perf”
OK: |’DiskFree’=0 ‘Y:’=3025MB;1227.2;920.4 ‘X:’=3006MB;1227.2;920.4 ‘Q:’=467MB;203.2;152.4

if ($perf) {$perf_list.add(@("DiskFree "+$i.path+"="+$i.FreeSpace+"MB`;"+($i.TotalSize*$diskWarn/100)+"`;"+($i.TotalSize*$diskCrit/100)))}
Es gab noch mehr verrückte Formatierungen, auf die ich gestoßen bin. Aber ich will euch nicht langweilen . . .
Letztendlich war ich positiv überrascht, das man mit etwas Aufwand doch recht angenehm unter Windows scripten kann.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Serie NSClient++ – Teil 8: Eigene Skripte

NSClient++ verfügt über eine Vielzahl von Abfragemöglichkeiten um Windows Server zu überwachen.
Viele der Überwachungsmöglichkeiten und Konfigurationsparameter für diese wurden bereits in der NSClient++ Serie vorgestellt.
Immer dann wenn weitere Applikationen, Hardware, Logdateien etc. überwacht werden sollen stoßen die NSClient++ Module überwiegend an die Grenzen ihrer Möglichkeiten. Eigene Skripte müssen her…
Das Modul CheckExternalScripts ist genau für diesen Zweck gedacht und dient als Wrapper um eigene Skripte auszuführen. Vorrausetzung hierfür ist das Windows die Skriptsprache unterstützt und das jeweilige Skript einen validen Icinga/Nagios Returncode zurückliefert.

NSClient++ und externe Skripte

In der NSC.ini beeinflussen die Folgenden Sektionen das verhalten der “ExternalScripts”:
[External Script] beschreibt das verhalten beim ausführen der Skripte. Mit “command_timeout=” wird der maximale Ausführungszeitrahmen (in Sekunden) eines Skripts/Plugins durch NSClient++ definiert. Achtung: NSClient++ bricht danach die Ausführung ab, unter Umständen kann das Skript jedoch weiterlaufen. Die Optionen “allow_arguments=” und “allow_nasty_meta_chars=” definieren ob beim ausführen von Icinga/Nagios Seite aus Argumente mit übergeben werden dürfen und ob “unangenehme” Zeichen übermittelt werden dürfen (z.B.: |`&><'"\[]{} ). Unter [Script Wrappings] werden die Interpreter für die verschiedenen Dateieindungen der Skripte konfiguriert. Mit den Variablen %SCRIPT% und %ARGS% wird definiert an welcher Stelle das Skript ausgeführt werden soll und wo beim Aufruf die Argumente übergeben werden.

vbs=cscript.exe //T:30 //NoLogo scripts\lib\wrapper.vbs %SCRIPT% %ARGS%
ps1=cmd /c echo scripts\%SCRIPT% %ARGS%; exit($lastexitcode) | powershell.exe -command -

[External Scripts] gibt nun schlussendlich die eigentlichen Skripte und ihre Ausführungsparameter an:

check_icinga.bat=scripts\icinga.bat

Oder auch, ohne den Skriptwrapper zu nutzen:

check_powershell_exchange=cmd /c echo scripts\exchange.ps1 | powershell.exe -command -

Sollen Skripte verwendet werden, die außerhalb des NSClient Verzeichnisses liegen muss jeweils der absolute Pfad verwendet werden.

Perlskripte unter Windows

Um Perl Skripte über den NSClient++ auszuführen benötigt man unter Windows entweder einen Perl Interpreter, z.B.: Strawberry Perl oder man kompiliert die jeweiligen Plugins zuvor mit dem Perl Modul PAR::Packer zu ausführbaren .exe Dateien:

$ perl -MCPAN -eshell
cpan> install Bundle::libwin32
cpan> install PAR::Packer
$ pp -o check_test.exe check_test.pl

Wer bei der Installation von PAR::Packer auf einen Fehler stößt: http://www.nntp.perl.org/group/perl.par/2012/03/msg5306.html

Weekly Snap: Powershell, AutoHotKey & Rockbox

 7 – 11 November was a Windows week, with tips on accessing databases via OSDB and managing hotkeys and script macros, topped off with a celebration of Rockbox.
Carsten started off by showing us how to use OSDB to access databases with Powershell. When an ODBC driver is only available for Windows and no extra script languages should be installed, he suggested Microsoft’s object oriented Powershell that comes with current Windows versions such as Windows Server 2008 R2 and Windows 7. Carsten shared an example script to demonstrate how to build a connection to a MSSQL database, run a query and show its results. For him it is ideal for use when developing Icinga plugins for Windows, which use an ODBC driver and are queried via NSClient++.
Following suit, Ronny recommended AutoHotKey for the management of hot keys and script macros in Windows. With the open source script language AutoHotKey, not only can frequently used entries such as “btw” be auto-expanded” to “by the way” but a whole range of queries, functions and applications can be set to respond to particular sequences of keystrokes and mouse clicks. Take a look at the tool’s documentation and wiki to understand the entire range of possibilities.
Last but not least, Ansgar wrote an ode to Rockbox, an alterative open source operating system for MP3 players. To overcome the deficiencies he saw in using the firmware that came with his iPod, he installed Rockbox. Now his player is capable of supporting more file formats, altering tone per equalizers and compressors, as well as being individualized with themes and games. With diverse applications, his iPod can display pictures or read text aloud and be transformed into a calculator or torch – pretty impressive for an open source makeover.

ODBC-Datenbankzugriff mit Powershell

Es gibt manchmal Situationen, in denen man eine Datenbank abfragen muss, der ODBC-Treiber allerdings nur für Windows verfügbar ist und auch keine zusätzliche Skriptsprache installiert werden soll.
Hierfür bietet sich Microsofts objektorientierte Powershell an, mittels derer ein Datenbankzugriff über ODBC relativ einfach zu bewerkstelligen ist. Die Powershell hat außerdem den Vorteil bei aktuellen Windows-Versionen wie z.B. Windows Server 2008 R2 und Windows 7 bereits vorinstalliert zu sein.
Anbei ein kurzes Beispielskript, das exemplarisch eine Verbindung zu einer MSSQL-Datenbank aufbaut, einen Query ausführt und das Ergebnis von selbigem anzeigt:

#DSN angeben, dabei sind _SERVERNAME_, _DATABASE_, _DBUSER_ und _DBPASSWORD_ jeweils zu ersetzen
$DBDSN="Driver={SQL Server};Server=_SERVERNAME_;Database=_DATABASE_;UID=_DBUSER_;PWD=_DBPASSWORD_;"
#Datenbankverbindungsobjekt instanzieren
$DBConnection=New-Object System.Data.Odbc.OdbcConnection
#DSN im Objekt setzen
$DBConnection.ConnectionString=$DBDSN
#Datenbankverbindung öffnen
$DBConnection.Open()
#Datenbankbefehlsobjekt instanzieren
$DBCommand=New-Object System.Data.Odbc.OdbcCommand
#Datenbankverbindung in Befehlsobjekt setzen
$DBCommand.Connection=$DBConnection
#Query angeben, dabei muss _QUERY_ durch das gewünschte Query ersetzt werden
$DBCommand.CommandText="_QUERY_"
#Ein Reader-Objekt erzeugen
$DBResult=$DBCommand.ExecuteReader()
#Anzahl der Rows zählen
#DBCounter=$DBResult.FieldCount
#Rows durchiterieren
while ($DBResult.Read()) {
	for ($i = 0; $i -lt $DBCounter; $i++) {
		#Rows formatiert ausgeben
		@{ $DBResult.GetName($i) = $DBResult.GetValue($i); }
	}
}
#Datenbankverbindung schließen
DBConnection.Close()

Das Skript ist in einer Datei mit .ps1-Endung zu speichern, anschließend muss noch die ExecutionPolicy auf RemoteSigned gesetzt werden, da sonst unsignierte Skripte auch lokal nicht ausgeführt werden dürfen:

PS C:\> Set-ExecutionPolicy RemoteSigned

Anschließend kann das Skript wie folgt aufgerufen werden:

PS C:\> .\odbc-test.ps1

Das Skript erzeugt in unserem Fall z.B. folgende Ausgabe:

Name Value
---- -----
Test Testvalue

Das ganze kann z.B. sehr gut dazu benutzt werden um Icinga-Plugins für Windows zu entwickeln, die einen lokalen ODBC-Treiber verwenden und per NSClient++ aufgerufen werden. Hierzu bietet es sich dann an das Skript mit entsprechenden Parametern zu erweitern und das Skript Exit Codes zurückliefern zu lassen. NSClient++ selbst bietet in seiner Standardkonfiguration bereits Beispiele, wie Powershell-Skripte anzusprechen sind.