Wie der Zauberlehrling kam ich mir vor als ich beim Kunden AutoIT für End2End-Monitoring nutzen wollte. AutoIT hatte ich davor nur für kleine Automatisierungen genutzt, war mir der Macht dieses Werkzeugs aber durchaus bewusst. Wie schick es ist diese auch für Monitoring zu nutzen liegt auf der Hand. Auch Kollegen haben davon schon berichtet und es wurden sogar ganze Vorträge darüber gehalten.
Die Automatisierung hat auch schnell geklappt und wenn die Programme ausgeführt wurden bewegte sich alles wie von Geisterhand. Die Ausgabe hat auch gefallen. Damit kommt der Punkt, alles so einzubinden wie es am Ende laufen soll und nun fingen meine Probleme an.
Diese will ich im folgenden einfach auflisten, vielleicht hilft es dem ein oder anderen, vielleicht hat ja noch jemand eine schlauere Lösung über die ich mich natürlich auch freue.
Mein erstes Problem waren die Möglichkeiten die WindowsXP einem Dienst zugesteht. Hier kann ich nur einem Dienst erlauben mit dem Desktop zu interagieren wenn er als lokaler System-Account läuft. Aber wenn das Programm aufgrund des SingleSignOn als ein anderer Benutzer laufen muss und die Meldung in einem Fenster auf dem Desktop erkennen soll? Alle Versuche mit RunAs scheiterten. Die Funktion in AutoIT hatte ein etwas anderes Verhalten der Anwendung zur Folge, ein Wrapperscript mit dem Windows-Kommando benötigt ein Passwort und alternative Werkzeuge verhinderten die Konsolen-Ausgabe.
Ein weiteres war das unterschiedliche Verhalten des NSClient (oder auch wieder von WindowsXP), ob nun das Programm direkt als .exe aufgerufen wurde oder ob eine .bat um den Aufruf des Programms herumgestrickt wurde. Zusätzlich änderte sich dieses Verhalten auch damit als welcher Benutzer der Dienst gestartet wurde und ob der NSClient zum Debugging im Vordergrund gestartet wurde.
Ein seltsames Phänomen, welches ich so nebenbei entdeckt hatte, war die Namensauflösung. Ohne Eintrag in der hosts-Datei war der Verbindungsaufbau extrem langsam wie ich schon beim Entwickeln festgestellt hatte. Lief der Check des Weblogins mittels Internet Explorer nun als System-Benutzer wurde wohl dieser Eintrag ignoriert, weshalb dieser regelmäßig in einen Timeout lief.
Diese Probleme hab ich dann im Kollektiv dadurch gelöst, dass ich meinen Benutzer für das End2End-Monitoring automatisch anmelde und den NSClient mit /test im Vordergrund starte.
Dazu kam dann noch das Problem, bei dem ich kurz davor war mit dem Lösungsweg des Zauberlehring zu liebäugeln. Ich mein damit „Mit dem scharfen Beile spalten“, höhere Mächte um Hilfe anflehen soweit war ich dann doch nicht. Da mir keine Konsole zur Verfügung stand, hatte ich mich mittels Remotedesktop auf den Client verbunden. Schau ich nun also per Remotedesktop den Geistern zu sind sie ganz brav und tun ihre Arbeit. Kaum hab ich die Sitzung minimiert oder geschlossen, bekomme ich je nach Skript unterschiedlichstes Verhalten. Der Weblogin im Internet Explorer funktioniert weiterhin, der Aufruf des Fatclients scheitert an den Fenstern und der Thinclient an der Erkennung der Meldung. Beim Versuch das Problem zu lösen, bin ich darüber gestolpert das AutoIT statt mit Titeln auch mit Handles arbeiten kann, was so mehr oder weniger gut in der Dokumentation versteckt war. Nachdem Umschreiben war wenigstens das Verhalten von Fatclient und Thinclient gleich. Dumm nur dass dies bedeutet gleich fehlerhaft!
Immer wieder auf Foreneinträge, Bugreports und auch hilfreiche Kollegen gestoßen, die nahelegten dass Remotedesktop das Verhalten von Fenstern unter WindowsXP stark verändern kann, kam ich mit dem Kunden überein eine Konsolensitzung zu brauchen. Mit der internen Standardlösung für Remotesupport ausgestattet und den Remotedesktop beendet, funktioniert alles plötzlich wie gewollt. Somit ist klar kein AutoIT mit Remotedesktop! Schlussendlich mussten die Geister nicht in die Ecke verbannt werden und Icinga ruft sie nun ganz wie der alte Meister zu seinem Zwecke und weiß nun dass der Benutzer auch wirklich seine Anwendungen benutzen kann.
0 Kommentare