Knutsens Blog - Informatik

VBS: Kontrollierter Reboot v. Windows-Systemen

nospam@example.com (Knutsen) — Wed, 03 Jun 2009 11:16:54 +0200

Die meisten Anwender an den 105 Workstations, die zu administrieren ich bei uns im Klinikum die Ehre habe, gehen nicht gerade pfleglich mit dem System um. Dazu gehört auch ein kontrollierter täglicher Reboot bei Windows-Systemen, einfach um viele Klippen zu umschiffen. Ich habe mittlerweile schon die krudesten Fehler gesehen, die daraus resultieren, daß ein System einfach eine Woche durchgelaufen ist (und in der Zeit exzessiv damit gearbeitet wurde). Die Ursachen müssen in den meisten Fällen nicht einmal Memory Holes im Windows-OS sein. Beispielsweise werden im Rahmen von Softwareverteilungen viele Updates bei Anwendungen durch Reboots bzw. bei Neuanmeldung eines Benutzers am System ausgelöst. Und wenn ein System niemals rebootet, bekommt es auch niemals Updates.

Aus diesem Grund habe ich mir ein kleines VBS gebastelt, welches folgende Aufgabe erledigt: Prüfe die aktuelle Uhrzeit des Systems und die Uptime. Liegt ersteres zwischen 00 und 06 Uhr und ist letzteres bei größer als 24 Stunden, so frage den Anwender, ob rebootet werden darf. Klickt der Anwender auf 'Nein' (weil er z.B. gerade bei einem sehr wichtigen Arbeitsschritt ist), so ~~nerve~~ frage ihn in Abständen von zehn Minuten immer wieder (auch wenn inzwischen 12 Uhr sein sollte). Sollte der Anwender die Dialogbox für 15 Minuten nicht beantworten, so reboote eigenständig.
Ist der Zeitpunkt oder die Uptime nicht wie oben angegeben, so soll natürlich nichts gemacht werden.
Die Reboot-Vorgang macht dasselbe wie ein "forced" Reboot, wie er z.B. nach Windows-Updates ausgelöst wird, wenn man sagt "Jetzt neu starten". Ein "unforced" Reboot hängt sich sehr oft noch an offenen Programmen auf.

Ich habe vorher im Netz geschaut, ob es schon vorhandene Scripts zu diesem Thema gibt, aber scheinbar wird dieses Problem immer durch Zusatzprogramme, die sich in die TrayBar legen, gelöst. Für mich ist jede zusätzliche Anwendung ein zusätzlicher Fehlerfall, darum vermeide ich dies am liebsten. Außerdem wird auf diesem Weg kein Speicher benötigt.
Apropos Speicher: Die regelmäßige Überprüfung geschieht aus Speicherspargründen per ~~Cronjob~~ Scheduled Task. Den Befehl, um diesen Taks zu erstellen, hänge ich unten mit an. Man kann natürlich auch dem Script eine Endlosschleife verpassen, und die Überprüfung auch so abfackeln. Aber bei meinem Arbeitsrechner benötigt die wscript-Umgebung 7 MB im Speicher, und bei einer Workstation mit 4 GB Memory sogar satte 100 MB (Warum?!).
"VBS: Kontrollierter Reboot v. Windows-Systemen" vollständig lesen

Screen-Mirroring beim Mac per Skript an/ausschalten

nospam@example.com (Ennonymous) — Wed, 12 Mar 2008 14:43:24 +0100

Heute habe ich meine Mittagspause mal wieder mit ein wenig Arbeitsplatzoptimierung verbracht. Bei mir im Büro steht ein Monitor und eine Tastatur, die via KVM-Switch an mein MacBook und an meinen Linux-PC angeschlossen sind. Normalerweise arbeite ich an meinem MacBook, das seinen Desktop dann über beide Monitor (den großen und das LCD vom Macbook selbst) verteilt. Wenn ich aber auf den Linux-Rechner umschalte, möchte ich oft gern, dass der Desktop des Macs nur noch das Notebook-LCD verwendet. Das kann man erreichen, indem man in der Menüleiste des Macs unter Displays "Synchronisierung einschalten" wählt, oder + auf der Notebook-Tastatur drückt.

Das ist mir aber beides zu umständlich - faul, wie ich bin, möchte ich weder nach meinem Notebook (d > 70cm) oder nach meiner Maus (d > 25 cm) greifen. Am liebsten wäre mir ein Tastaturkürzel auf meiner externen Tastatur. + klappt da leider nicht, also habe ich mir folgendes Apple-Skript auf + gelegt (z.B. mit Butler):

"Screen-Mirroring beim Mac per Skript an/ausschalten" vollständig lesen

Web-Apps auf dem Desktop

nospam@example.com (Ennonymous) — Fri, 08 Feb 2008 11:40:54 +0100

Ich benutze für meine persönlichen und arbeitsbezogenen Notizen ein DokuWiki, das ich auf meinem Mac lokal hoste. Nun finde ich es simmer ein bisschen nervig, jedesmal ein neues Browserfenster zu öffnen, um durch meine Notizen zu blättern bzw. neue ins Wiki aufzunehmen; auch ärgert es, wenn eine Seite den ganzen Browser zum Absturz bringt und dabei nicht gespeicherte Änderungen im Wiki gleich mit sich reißt.

Auf meiner Suche nach Abhilfe bin ich über Fluid gestolpert. Fluid nimmt einfach eine URL und erstellt eine eigenständige Applikation, die (mithilfe des WebKits von Apple) nur diese Seite darstellt. Das ganze sieht für mein Wiki dann beispielsweise so aus:

Zu beachten ist, dass das ganze eine eigene Applikation (mit eigenem Icon im Dock) ist. Sehr praktisch. Mozilla bietet mit Prism etwas ganz ähnliches, falls man keinen Mac zur Hand hat.

Morgenstund' hat Gold im Mund...

nospam@example.com (Ennonymous) — Mon, 04 Feb 2008 08:09:24 +0100

Ein notorischer Langschläfer - das ist es, was ich eigentlich bin. Trotz der offensichtlichen Vorteile, die Frühaufsteher genießen. Nun, heute konnte ich einen davon am eigenen Leib erfahren: die Aussicht um 8 Uhr aus meinem Bürofenster:

Sonst kenne ich solche Sonnenaufgänge nur von meinem Desktop-Hintergrund... Ich glaub' ich mach das öfter.

Cacti: Graphen

nospam@example.com (Knutsen) — Sun, 03 Feb 2008 18:01:15 +0100

Ennonymous hat neulich über Cacti geschrieben, da dachte ich, ich streu mal noch etwas motivierenden Zucker, was man so alles damit machen kann. Die Graphen bitte anklicken, um sie in ihrer korrekten Größe zu sehen.

Hier ist sehr gut der Verlauf bei einem Authentifizierungs-Server zu sehen. Wie man sieht liegt die Hauptarbeitszeit der Nutzer in der Mitte des Tages, also ca. um 12:00 Uhr. Der 26. und 27. waren Wochenendtage, wo nur leichte Anstiege zu verzeichnen sind.
"Cacti: Graphen" vollständig lesen

Vorsicht, heiß - oder: Wie man seinen Montag abend sinnvoll mit Linux vertrödeln kann

nospam@example.com (Ennonymous) — Mon, 28 Jan 2008 22:27:12 +0100

Zeit für einen Gastauftritt.

Ich habe gerade an meinem Heim-Server in kleinlichster Sisyphusarbeit die Sensordaten der Hardwareüberwachung lm_sensors in eine dauerhafte Statistik (über das Tool Cacti) übernommen. Dazu gehören neben CPU- und Systemtemperatur sowie Lüfterdrehzahl auch die Spannungswerte der Stromversorgung. So kann ich (hoffentlich) ziemlich genau sehen, wenn sich Schwächeanfälle anbahnen... und außerdem ist es irgendwie cool. Zumindest für Menschen ohne Leben wie mich.

Da es schon spät ist und ich meinen Hintern schon seit drei Stunden in mein Sofa bohre, gibt's nur eine Kurzversion - ich hoffe, dass sie trotzdem für jemanden nützlich sein kann. Sie ist auch ein schönes Beispiel dafür, wie man mit wenig Aufwand und ein paar UNIX-Bordmitteln schnell eine brauchbare Lösung häkeln kann.
"Vorsicht, heiß - oder: Wie man seinen Montag abend sinnvoll mit Linux vertrödeln kann" vollständig lesen

Vollständig entfernen...

nospam@example.com (Knutsen) — Wed, 09 Jan 2008 19:45:36 +0100

Eine neue Lehre mit Linux (Ubuntu): Man sollte nicht leichtfertig Pakete in Synaptic zum "vollständigen Entfernen" vormerken. Sonst sieht das Startmenü plötzlich aus wie ein gerupftes Huhn. Von 70 Einträgen befinden sich jetzt vielleicht noch 20 Einträge im Menü, obwohl ich nur kurz CUPS vollständig vom System tilgen wollte. Einmal zu oft auf "Jaja, mach mal..." geklickt, und er hat mir ein paar Pakete mehr zum Entfernen markiert, als ich wollte. Wundern tat ich mich, als plötzlich über 1 GB gelöscht werden sollte. Nein, CUPS ist nicht SO groß! Mit großen Augen musste ich mit ansehen, wie mein Network-Manager, Firefox, Amarok und andere Sachen über den Jordan gingen.... "WO IST HIER ABBRECHEN?!"... Gibt's natürlich nicht. Also STRG-ALT-F1, Login, "ps -ef | grep synaptic" und "SUDO KILL 6411"! (Nicht unbedingt in Großbuchstaben...)

Jetzt bin ich erstmal am Pakete reinstallieren... ja, die eigene Blödheit. Dafür ist CUPS jetzt wenigstens weg. Tot. Gekillt. Weg. So.

Hardwaregewühle

nospam@example.com (Knutsen) — Mon, 19 Nov 2007 21:59:32 +0100

Die insgesamt 120 Workstation, die später die Clients für das PACS spielen werden und an denen unter anderem die Radiologen dann die Röntgen-, CT-, MRT- oder andere Bilder befunden werden, sind getrennt von den Grafikkarten angeliefert worden. Da jede Workstation bis zu fünf (meistens aber zwei oder drei) Displays zur Ausgabe bekommt, heißt das ordentlich Grafikkartenstöpselei. Der Müll, der bei so etwas anfällt, sei im folgenden präsentiert:

Das ist die Hälfte des Haufens für Lübeck.

Eine anstrengende Woche...

nospam@example.com (Knutsen) — Sun, 18 Nov 2007 18:48:11 +0100

Dieses Blog muss reaktiviert werden. Diese Maxime habe ich mir auf die Fahnen geschrieben. Den Anfang soll ein knapper Artikel über die momentane Arbeitssituation bei mir in der Firma machen.

Bedingt durch das aktuelle Großprojekt ist die Stimmung im Büro allgemein sehr gehetzt und gestresst. Am 2.1.08 soll das neue Krankenhaus-Informations-System online gehen. Zur Verdeutlichung: Ein komplettes Krankenhaus, verteilt auf zwei große Campi in zwei Städten, mit ungefähr 10.000 Mitarbeitern stellt die gesamte EDV um. Einige Systeme bleiben zwar bestehen, werden aber an das neue KIS angebunden, weswegen man von 'komplett' guten Gewissens sprechen kann.

Da es keine nennenswerten Neueinstellungen gab, müssen alle Mitarbeiter (rund 80) in der IT nun neben dem Routinejob auch die Installation, Konfiguration und Vorbereitung des neuen Systems mit erledigen. Glücklicherweise leistet die Firma, die das System anbietet, den Löwenanteil. Jedoch genügt die Restarbeit, um alle zum Schwitzen zu bringen.

Für meine Person heißt das neue System: An der Einrichtung von 10-15 neuen Servern beteiligt zu sein, und die Aufstellung von 120 Clients auf zwei Campi (ergo in zwei Städten, ergo viele Diestreisen) zu managen, von der Installation bis zur Aufstellung. Was das im Detail heißt, möchte ich in den folgenen Artikeln noch näher erläutern.

Es genügt für den Moment zu sagen: Dank Telefon-(Hotline-)Dienst diese Woche habe ich insgesamt 57 Arbeitsstunden abgeleistet. Angenehm ist was anderes. Aber es ist all-in-all durchaus spannend.

Mobil bei Arbeit, Sport & Spiel

nospam@example.com (Knutsen) — Mon, 02 Jul 2007 23:07:37 +0200

Die letzten Wochen bersteten vor privaten Aktivitäten und Terminchen, und auch auf der Arbeit ist momentan reichlich zu tun. Zur Erinnerung: Das Krankenhaus, in dem ich arbeite, will zum Jahreswechsel ein komplett neues Informationssystem für all ihre Patientendaten, etc. einführen. Ein echtes Mammutprojekt, in das ungefähr 100 Personen direkt durch die Einrichtung und Inbetriebnahme und tausende Angestellte indirekt als Anwender involviert sind. Und mittlerweile habe auch ich als Hardware-Administrator des neuen PACS, des Teils des Systems, das Bilddaten aus CTs, MRTs, etc. speichert, die erste Hardware vor der Bürotür stehen. Davor haben aber die Götter die Routine gesetzt: Das alte System wurde vorletzte Woche noch einmal upgedated, was zu einem abendlichen Ausfall und zu vermehrten Überstunden bei der EDV-Belegschaft führte. Da ich an diesem Tag Frühdienst hatte, war ich satte 16 Stunden auf der Arbeit, von 6:15 bis 22:30 Uhr. An dem Abend war ich mehr als erledigt.
"Mobil bei Arbeit, Sport & Spiel" vollständig lesen

Working (with) Ubuntu 7.04

nospam@example.com (Knutsen) — Fri, 27 Apr 2007 18:45:53 +0200

Nach ein paar Tagen, wo ich leider nicht allzuviel austesten konnte, arbeite ich schon recht regelmäßig mit Ubuntu auf meinem Notebook - meinen Desktop-PC würdige ich kaum noch eines Blickes und ich brauche ihn eigentlich nur, weil ich noch haufenweise Daten drauf habe. Es wäre eine Überlegung wert, ihn sozusagen als Mini-Terminalserver in die Abstellkammer zu stellen für die wenigen Windows-Anwendungen, die man noch benötigt. Aber auf der anderen Seite möchte man ja auch öfter noch was zocken und dafür nicht in eine Abstellkammer verschwinden.

Nach meinem letzten Artikel habe ich nur noch die 3D-Funktionen getestet, die sich bei Ubuntu auf Knopfdruck und Reboot aktivieren lassen. Und in der Tat funktionierte es mit meinem Chipsatz, dem Intel 945G, ohne Probleme. Nennenswerte Geschwindigkeitseinbußen habe ich nicht feststellen können. Ich muss nur herausfinden, ob ich den Eye-Candy wirklich benötige. Zumal ein Programm bei mir durch den Kram keine Inhalte in seinem Fenster mehr anzeigt.

Update: Soeben haben wir es auch hinbekommen, daß mein Notebook über eine Drucker-Freigabe am (inzwischen ebenfalls Ubuntu-)Rechner meiner Freundin druckt.

Ubuntu 7.04 - Feisty Fawn

nospam@example.com (Knutsen) — Mon, 23 Apr 2007 18:51:44 +0200

Heute Morgen habe ich Ubuntu 7.04 auf meinem Dell Latitude D420 installiert, und ich muss sagen: Es rockt! Die wenigen Probleme, die ich bei Kubuntu 6.10 noch hatte, haben sich weiter minimiert. Nach einem Boot von der Live-CD betätigte ich den Install-Button. Mit dem Installer kann man recht schnell eine eventuell vorhandene Windows-Partition verkleinern und im frei gewordenen Bereich Ubuntu installieren. Ich muss zwar noch testen, ob das Windows das überlebt hat, aber ich nehme es einfach an. Ansonsten gibt es hier spätestens morgen noch ein Update. Wäre aber auch nicht schlimm drum, weil mein Notebook insgesamt noch sehr neu ist und ich sowieso bisher nichts im Windows gemacht habe.

Nach der Installation präsentierte sich mir Ubuntu wie schon bei der Live-CD in 1024*768. Da ich auf Arbeit nur nebenher die Installation angestoßen hatte und ich zu diesem Zeitpunkt noch anderes zu tun hatte, vertagte ich die mir schon von Kubuntu bekannte Installation des 915resolution-Paketes auf später. Zuhause dann kurz gejubelt, weil auch WLAN wieder sofort funktionierte, den Paketmanager Synaptic gestartet und 915resolution nachinstalliert. Die Ausgabe ließ mich vermuten, daß die native Auflösung meines Display von 1280*800 automatisch erkannt wurde - und ein mutiger Test mit STRG-ALT-Backspace (Neuinitiierung X-Server) bestätigte diese Vermutung. Damit musste ich nicht einmal mehr ein einziges Config-File anfassen.

Danach richtete ich mit Synaptic noch die Software ein, die ich vorher unter Kubuntu schon schätzen gelernt hatte: X-Chat (IRC), Gaim (ICQ), Thunderbird (eMail) und RDesktop (RDP auf meinen Desktop-PC). Absolut begeistert bin ich von Gnome. Bisher hatte ich nur KDE und in grauer Vorzeit den fvwm als Window-Manager genutzt. Gnome hatte ich einmal ausprobiert, aber dann sofort verworfen, weil mir die GUI einfach nicht zugesagt hatte. Nachdem mich aber KDE unter Kubuntu 6.10 nicht wirklich vom Hocker gerissen hatte, entschied ich mich einfach für einen neuen Versuch. Und was soll ich sagen.... zum einen wirkt der Desktop einfach viel aufgeräumter; rein subjektiv habe ich das Gefühl, daß ich unter Gnome mehr Platz habe als vorher unter KDE bei derselben Auflösung. Darüber hinaus wirken die Administrationstools irgendwie stabiler und funktioneller. Last but not least: Gaim und XChat lassen sich wie bei Windows in die Symbolleiste minimieren und (wichtig!) mit einem Single-Klick wieder aufrufen. Kleine Ursache, große Wirkung: Will man nur schnell nachschauen, was sich in den Chats tut, reichen zwei Klicks, und es sind nicht zwei Doppelklicks notwendig wie unter anderen GUIs.

Ach ja, einziger Nachteil momentan: mp3s wollen nur unter speziellen, nachinstallierten Playern, weil der mp3-Support bei Ubuntu aus Lizenzgründen nicht von vornherein mitgeliefert ist. Aber irgendwie biege ich das auch noch hin.

Tja, zu mehr bin ich nicht gekommen. Mein Fazit: Der Einstieg in Linux ist eindeutig leichter geworden. Selbst bei einem Notebook mit Hardware-Komponenten etwas außer der Reihe klappt das komplette Aufsetzen eines funktionierenden Grundsystems mit GUI, WLAN/Internet und wenigen speziellen Anwendungen mit etwas Grundwissen (durch eine Woche Kubuntu-Nutzung) innerhalb von zwei Stunden. Wobei Ubuntu unbestritten eine der einsteigerfreundlichsten Distributionen mit der Zielgruppe der abwanderungswilligen Windowser sein dürfte.

DICOM-Schulung

nospam@example.com (Knutsen) — Fri, 16 Feb 2007 17:33:38 +0100

Montag und Dienstag diese Woche befand ich mich in Oldenburg auf einer Schulung, was mir wieder eine gute Ausrede verschafft, warum ich länger nichts geschrieben habe. Die Vorträge waren höchst interessant, und ich fühlte mich in die Zeit meines Studiums versetzt, als ich noch die ganze Woche das Glück hatte, dersolchen zu lauschen. So waren die zwei Tage auch trotz des frühen Aufstehens um 04:30 Uhr am Montag fast wie Urlaub: Gemütlich im Vorlesungsraum sitzen, Abends ein wenig durch eine fremde Stadt schlendern und dann im Hotel abhängen. Und am nächsten Morgen ein reichhaltiges Frühstück.

In der Schulung selbst ging es um den Bereich DICOM. Dabei handelt es sich um eine Art Protokollsprache zwischen Modalitäten wie CTs oder MRTs und dem Bildarchivierungssystem PACS. Wie man sich leicht vorstellen kann, benötigt es eines vernünftigen (Quasi-)Standards, damit die zahlreichen Modalitäten verschiedenster Hersteller und die verschiedenen PACS-Systeme miteinander komunizieren können. Der DICOM-Standard liefert diese Funktionalität.

Ein Beispiel: Ein Tomographiegerät soll eine ganze Serie von Bildern liefern, da ein Patient sich den Arm gebrochen hat. Zuerst werden daher die Patientendaten eingeben, was entweder per Hand an der Modalität geschehen kann (wohl kaum noch) oder auf digitalem Wege durch ein Informationssystem, vielleicht ein RIS (Radiologie-IS). Die MTA positioniert den Patienten im Tomographen und stößt die Untersuchung an. Das Gerät erkennt dann die Position und schießt eine ganze Serie von Bildern, die es danach auf bestimmte Weise im DICOM-Format kodiert. Entweder werden die unkomprimierten Pixeldaten einfach so mit den Patientendaten, Aufnahmezeitpunkt, Modalitätsname, etc.pp. im Header verknüpft oder die Bilder werden noch vorher beispielsweise in JPEGs komprimiert, was verlustfrei (z.B. Lauflängenkodierung) oder verlustbehaftet (näheres in JPEG) geschehen kann. Der Bilderstrom wird schließlich über das LAN ans PACS geschickt.

Dummerweise ist der Standard DICOM ein ziemlich weicher Standard. DICOM selbst deckt nämlich extrem viele Funktionalitäten in Form von sogenannten Diensten ab. Und nicht jedes Gerät, das sich DICOM-Konformität auf die Fahnen schreibt, muss wirklich alle Dienste beherrschen, um DICOM-konform zu sein. Ist ja auch sinnvoll: So muß eine Modalität kaum den DICOM-Druckdienst anbieten, wenn sie nicht drucken kann. Jedoch gibt es auch innerhalb der Header-Segmente innerhalb der DICOM-Klassen bestimmte Segmente, die Modalitäten nicht implementieren müssen. Einzig vorgeschrieben ist daher, daß jedes Gerät, das sich DICOM-konform nennt, ein sogenanntes "Conformance Statement" mitführt. Dies ist ein Paper von ungefähr zwanzig Seiten Länge, wo genau aufgeführt ist, was an DICOM-Diensten und Header-Segmenten unterstützt wird und was nicht. Und wenn man selbst als Firma beispielsweise ein neues PACS einführt, muß man selbst genau darauf achten, ob das PACS sich auch mit allen Modalitäten unterhalten kann. Ergo: Haufenweise Conformance Statements wühlen.

EventLogs: So einfach kann es sein

nospam@example.com (Knutsen) — Sun, 11 Feb 2007 12:07:12 +0100

Neulich hatte ich über den LogParser berichtet und mich am Ende darüber geärgert, daß meine Versuche, EventLogs von anderen Computern auszulesen, (verständlicherweise) auf Grund fehlender Rechte fehlschlugen. Am Tag darauf habe ich dann doch noch eine Lösung, sogar in Form eines fertigen Scripts, entdeckt. Auf dieser Unterseite findet man es unter der Überschrift "Pulling Event Logs". Erfreulich an der Geschichte ist, daß ich damit auf den Servern gar nichts mehr installieren muß. Auf dem Client MySQL starten, einen Server sowie einen darauf befindlichen User-Account incl. Passwort mit den entsprechenden Rechten angeben und fertig. Als nächstes werde ich mir noch ein schönes Tool bauen, das mir Warnungen und Fehler übersichtlich präsentiert.

VBS, LogParser, EventLogs und WMI

nospam@example.com (Knutsen) — Wed, 07 Feb 2007 19:04:27 +0100

Momentan bin ich dabei, mich in das Scripting unter Windows mit VBScript einzufuchsen. Bis zu Beginn der Woche hatte ich mit VBScripten höchstens in Form von nervigen eMail-Anhängen zu tun, insofern also manches aufzuholen. Mit Visual Basic hatte ich mal in grauer Vorzeit was programmiert, aber das war sogar noch vor dem Studium gewesen; und richtig vergleichen kann man beides auch nicht miteinander. Begeistert bin ich von der Syntax der VBScripte nicht; für mich als Java/C++/php-Erfahrener eher gewöhnungsbedürftig. Aber gut, in Perl habe ich mich auch irgendwie eingefuchst, dann sollte VBScript wohl ein Kinkerlitzchen dagegen sein.

Nutzen möchte ich VBScript momentan dafür, bestimmte Inhalte aus EventLogs von Servern unter Windows 2003 zu sammeln und an eine zentrale Stelle zu schicken, nämlich meinen Arbeits-PC. Auf diese Weise müßte ich mich nicht täglich auf x Servern einloggen, um dort nach dem Rechten zu sehen. Gut: Momentan sind es nur 2(3) Kisten, die ich beobachten muss, das geht noch fix. Aber wenn wir bald die neuen Systeme bekommen, wird sich die Anzahl drastisch erhöhen.

Zuerst hatte ich mir ein kleines Script geschrieben, das die EventLogs per WMI sozusagen händisch ausliest. Aber wie das so oft ist, habe ich kurz danach ein freies (unoffizielles) Tool von Microsoft entdeckt, das diese Aufgabe übernimmt und noch vieles mehr kann. LogParser kann Logs aus 15-20 verschiedenen Quellen (EventLog, CSV, Text-Dateien, ...), darüber einen SELECT fahren und das Ergebnis wiederum strukturiert einem Ziel übergeben, das z.B. auch eine SQL-Datenbank sein kann. Nun musste ich heute nur noch ein kleines Script zusammentackern, das per Scheduler und LogParser automatisch um 00:05 die EventLogs des letzten Tages ausliest, in eine CSV-Datei verpackt und meinem Arbeits-PC übergibt. Dort kümmert sich ein weiterer Task per LogParser darum, die Inhalte der CSV-Datei in die SQL-Datenbank zu hauen.

Theoretisch wäre es auch möglich gewesen, direkt auf dem Server per LogParser die Daten der SQL-Datenbank auf meinem PC zu übergeben. Aber um mit einer SQL-Datenbank kommunizieren zu können, benötigt LogParser einen ODBC-Treiber. Und den wollte ich nun doch nicht auf x Servern installieren, da ich nicht scharf auf etwaige Seiteneffekte bin. Die Anwendung auf den 3 genannten Servern ist nämlich nicht die stabilste. Aber vielleicht ist dies eine Option für die Zukunft.

Optimal wäre es gewesen, wenn ich die oben beschrieben Push-Variante (Push, weil der Server meinem PC die Daten übergibt, sie also sozusagen rüberschiebt) hätte sein lassen können. Aber die Pull-Variante, nämlich die direkte Abfrage der EventLogs von meinem Arbeits-PC, scheidet leider aus, weil das Windows auf den Servern die EventLogs teilweise sperrt. Verständlich: Die Server sind in einer eigenen Domäne und mein Arbeits-PC hat da nicht allzuviel zu melden.