Skripte laufen unter Windows Server 2008 und 2012 nicht zuverlässig

  • Hallo zusammen,

    ich habe das Problem, dass AutoIt (sowie Autohotkey) meine Skripte nicht ausführt.
    Betriebssystem ist Windows Server 2008 32bit und Windows Server 2012 64bit.

    Über Google habe ich gefunden, dass es womöglich Probleme mit den Rechten geben soll.
    Daraufhin habe ich eine .exe erstellt und als Admin gestartet, was nicht zur Lösung führte. Ebenfalls habe ich probiert, die UAC zu deaktivieren, was die Skripte auch nicht zum Laufen brachte.
    Auch die .exe per Taskplaner nach dem Login in Windows mit höchsten Rechten funktioniert nicht.

    Das Interessante ist, dass nicht mal die Beispiele von AutoIt (im Examples Ordner) funktionieren.
    Ich führe zum Beispiel das Taschenrechner Beispiel aus, es kommt die MsgBox und bei Bestätigung das Rechenprogramm, aber danach erfolgen keine Tastatureingaben.


    Als ich ein Skripte erstellt habe, funktionierte es noch. Dann habe ich es in den Autostart aufgenommen und von da weg gab es Störungen beim Ablauf.
    Meistens sehen die so aus, dass keine Tastenkombinationen (z. B. ein schlichtes Send("^c")) und auch Mausbewegungen und -klicks nicht funktionieren.
    Auch lustig ist, dass z. B. bei einem ControlSend("Fenster","","ID","email@adresse.xy") die Ausgabe emailqadresse.xy ist. Das gleiche passierte sogar, als ich @ mit {ASC 064} ersetzt hatte.

    Nachdem ich dann eine Weile lang mit AutoIt ein paar Skripte bearbeite und ausführe, funktionieren auf einmal die Send Befehle wieder und die Skripte laufen wie gewünscht ab.

    [size=10]Ich kann mir daraus keinen Reim machen und hoffe, dass ihr mir helfen könnt.
    Folgendes Skript mal als Beispiel:

    [autoit]

    #RequireAdmin
    AutoItSetOption("MouseCoordMode", 0)
    WinMinimizeAll()
    Sleep(3000)
    Run("Programm.exe")
    WinWaitActive("Programm")
    Sleep(8000)
    MouseClick("left", 168, 250, 2, 1)
    Sleep(5000)
    Send("^c")
    Run("AnderesProgramm.exe")
    WinWaitActive("AnderesProgramm")
    ControlSend("AnderesProgramm", "", "[AnderesProgramm:Edit2]", "email{ASC 064}adresse.xy")
    Sleep(200)
    Send("^{Enter}")
    WinWaitClose("AnderesProgramm")

    [/autoit]

    Einmal editiert, zuletzt von Jim (25. Februar 2013 um 06:03)

  • Hi,
    ich arbeite täglich mit mehreren größeren AutoItscripten in Produktivumgebung. Auf Server 2008, und div. BS als Clients. Überall ohne besondere bzw. Admin-Rechte, eher komplett ohne alle Rechte, wie sich das gehört.
    Ich habe auch noch nie bemerkt, dass es Probleme gäbe, die Server 2008-spezifisch wären. Einige Scripte laufen nachts stundenlang, aktivieren diverse Programme von Drittherstellern, lesen dort Daten aus und schicken mir im Fehlerfall (und natürlich im Erfolgsfall) Mails. Die Fehlermails gibt es höchstens, wenn ein Mensch vorher fehlerhafte Daten eingegeben hatte. Aus technischen Gründen gabs noch keine.

    Daher würde ich in Deinem Fall davon ausgehen, dass der "Fehler" nicht an AutoIt liegt, was auch diese Aussage bestätigen würde:

    Zitat

    Nachdem ich dann eine Weile lang mit AutoIt ein paar Skripte bearbeite und ausführe, funktionieren auf einmal die Send Befehle wieder und die Skripte laufen wie gewünscht ab.

  • Hallo Andy und danke für deine Antwort.
    Ich bin auch verwundert, dass nach einer Weile die Skripte reibungslos ablaufen.
    Es scheint also nicht an AutoIt selbst zu liegen, da es ja später dann funktioniert, aber an was könnte es denn liegen?
    Und warum funktioniert es nach einem Neustart nicht, sondern erst nachdem ich ein paar andere Sachen auf dem Server gemacht habe?
    Irgendwelche Ideen? Hat es vielleicht irgendwas mit der Remotedesktopverbindung oder VNC zu tun? Keyboard/Maus Emulation oder oder?

  • Ich meine mich zu erinnern das ich manchmal Probleme hatte mit RDP und laufenden Autoit Scripts.
    Zumindestens wenn ich mich dann abgemeldet habe. Kann aber auch was anderes gewesen sein^^

  • Hi,

    Zitat

    Zumindestens wenn ich mich dann abgemeldet habe.

    naja, bei einer remoteverbindung ein Script (lokal) zu starten, sich dann im Kontext abzumelden und dann zu erwarten, dass das Script weiterläuft ist in etwa so wie mitten beim Bergsteigen das Seil durchzuschneiden und oben auf dem Gipfel bei Nachfrage nach dem Kumpel zu sagen :"Komisch, bis vor 10 Minuten hing er noch dran..." ?(

    Btw, verbinde ich mich mit mehreren Servern, bin aber noch nie auf die Idee gekommen, während der laufenden Scripte die Session zu wechseln, das werde ich mal testen.

    Zitat

    Und warum funktioniert es nach einem Neustart nicht, sondern erst nachdem ich ein paar andere Sachen auf dem Server gemacht habe?

    dazu weiss ich zuwenig, ggf hängt es daran, dass bestimmte Dienste erst mit Verspätung gestartet werden.
    Mein Laptop bspw. zeigt beim booten den Desktop mit Win7 sehr schnell, alledings ist der Bootvorgang erst wesentlich später komplett abgeschlossen! Auf einige Dienste habe ich erst nach ca 1-2min Zugriff.

  • Send und mouseclick funktionieren bei RDP Sessions ohnehin nur wenn wirklich jemand eine aktive Session hat. Sobald man die RDP Session trennt ist es aus damit. Was aber funktioniert sind die winXXX und controlXXX Funktionen. Letztere sind ohnehin zu bevorzugen, da das Senden von Tastenkombinationen ohnehin nicht besonders zuverlässig funktioniert und hin und wieder mal ins leere läuft. Statt controlsend würde ich aber nach Möglichkeit controlsettext verwenden. Viel besser wäre allerdings wenn du komplett auf aktive Fenster, Maus und Tastaturbefehle verzichten kannst und die Programme rein durch Parameter Aufrufe mit Daten versorgst.

    Deine Mausklick Zeile im relativen Koordinaten Modus wird btw immer dann scheitern wenn innerhalb der 8 Sekunden nachdem das Fenster aktiv wurde noch andere Fenster aktiv werden. Das selbe dann beim send. Hier können theoretisch 5 Sekunden lang andere Fenster den Focus bekommen und dein send im falschen Fenster landen.

    Einmal editiert, zuletzt von misterspeed (23. Februar 2013 um 12:13)

  • Danke für eure Beiträge.

    Zitat

    Mein Laptop bspw. zeigt beim booten den Desktop mit Win7 sehr schnell, alledings ist der Bootvorgang erst wesentlich später komplett abgeschlossen! Auf einige Dienste habe ich erst nach ca 1-2min Zugriff.


    Im Aufgabenplaner habe ich die Aufgabe mit einer Verzögerung von 3 Minuten nach dem Einloggen eingestellt, da ich auf Nummer sicher gehen wollte, dass das System auch wirklich komplett gestartet ist.
    Allerdings hat das nichts gebracht.

    Zitat

    Send und mouseclick funktionieren bei RDP Sessions ohnehin nur wenn wirklich jemand eine aktive Session hat. Sobald man die RDP Session trennt ist es aus damit. Was aber funktioniert sind die winXXX und controlXXX Funktionen.


    Das ist interessant, weil Send und MouseClick tatsächlich am Anfang nicht funktionieren, Win* und Control* jedoch schon (auch wenn das @ Zeichen als q ausgegeben wird)
    Allerdings habe ich nach dem Einloggen die RDP Session weiterhin aktiv und schaue mir den Ablauf des Skriptes an. Auch wenn ich statt der Remotedesktopverbindung (die sich ja immer anmeldet und abmeldet) VNC benutze, passiert das Gleiche.

    Werde mal noch etwas weiter testen und auf jeden Fall melden, wenn ich eine Lösung gefunden habe. Vielleicht fällt euch ja noch was ein.

  • Habe neue Erkenntnisse gewonnen.
    Gestern habe ich nach einem Neustart versucht, die Skripte zu starten, was fehlschlug.
    Danach habe ich einfach nur den Server gesperrt und habe die VNC Verbindung beendet.
    Gerade eben habe ich gestestet, ob die Skripte nun funktionieren und siehe da, sie laufen fehlerfrei ab.
    Scheint also wirklich an irgendetwas zu liegen, was längere Zeit zum Laden braucht.
    Bleibt mir also noch herauszufinden, nach welcher Zeit etwa die Skripte laufen...
    Mal sehen.
    Danke auf alle Fälle für eure Beiträge.

  • Hat hier vielleicht nix verloren aber man kann die Prozesspriorität in den Server versionen nicht so einfach ändern.
    (Klappt wohl ab und an aber halt nicht immer)
    Wer das vorhat und zufällig hier gelandet ist dem Empfehle ich Richtlinien

    -

  • Hi,
    ich hole diesen Thread nochmal nach vorne weil ich heute bei folgendem Problem nicht weiterkomme.

    Habe ein AutoIt-Script erstellt, welches über COM auf div. Excel-Tabellen zugereift. Dieses Script läuft tadellos in meinem und in anderen (u.a. Admin-) Usercontext.
    Nun kam unser Admin auf die Idee, dieses Script per Taskplaner auf dem Server 2008 zu starten, nachdem er sich (als Admin auf dem Server) per Doppelklick zum Starten davon überzeugt hatte, dass alles einwandfrei läuft. Das Script als EXE-Datei startet, die Excel-Files werden bearbeitet, alles schick.
    Also das Script in den Taskplaner des Servers eingetragen, testweise aus dem Taskplaner gestartet und das Script läuft nur so lange, bis die COM-Verbindung zu Excel hergestellt wird. Dann bleibt das Script ohne Fehlermeldung und ohne COM-Fehler einfach stehen.
    Wir haben schon mit den Rechten experimentiert und sämtliche Möglichkeiten in den Einstellungen des Taskplaners durchprobiert.
    Ich habe schon die #RequireAdmin eingebaut, das Script unter x86 und x64 compiliert. Wie gesagt, von Hand gestartet läuft es einwandfrei, im Taskplaner bleibt es genau an der Stelle an der

    [autoit]

    Filewrite("Test1.txt"," ") ;Datei wird erstellt, testweise
    $oExcel = ObjCreate("Excel.Application") ;hier bleibt das Script stehen
    Filewrite("Test2.txt"," ") ;Datei wird nicht erstellt

    [/autoit]

    aufgerufen wird, stehen.
    Bei der Abfrage des COM-Error schreibe ich auch in der ersten Zeile eine Testdatei, aber dort kommt das Script nie an.

    Hat jemand die Möglichkeit, dieses Phänomen auf Server 2008 zu testen oder weiss jemand, an was das liegen könnte?

  • Hi,

    liegt vielleicht am Kontext des Taskplaners...

    Läuft der Taskplaner nicht mit Systmerechten?

    Hat das "System" (der Server selbst) Berechtigungen auf diese Excel-Dateien zuzugreifen?

    Falls der Zugriff über einen (Netzwerk-)Share auf die Excel-Dateien erfolgen soll, muss der Server die Berechtigung bekommen darauf zuzugreifen.
    Dafür ist es nötig den Gruppen Network und Domain Computers (in einer Domäne) zumindest Leserechte auf diesem Share zu erteilen.

    mfg
    ahe

    There exist 10 different kind of people on earth.
    Those who understand binary, and those who don't.

  • Hi,
    Danke für die Antwort.

    Zitat

    Läuft der Taskplaner nicht mit Systmerechten?

    Muss ich prüfen, wäre aber ein Ding, da auch andere Tasks problemlos zumindest diese Excel-Dateien kopieren...

    Zitat

    Hat das "System" (der Server selbst) Berechtigungen auf diese Excel-Dateien zuzugreifen?

    Es wäre schon schön, wenn vor dem Zugriff auf die Datei Excel erstmal starten würde^^

    Zitat

    Falls der Zugriff über einen (Netzwerk-)Share auf die Excel-Dateien erfolgen soll, muss der Server die Berechtigung bekommen darauf zuzugreifen.
    Dafür ist es nötig den Gruppen Network und Domain Computers (in einer Domäne) zumindest Leserechte auf diesem Share zu erteilen.

    Das hatten wir überprüft und auf Dateien zugreifen wollen, die nicht freigegeben waren. Da dort aber kein COM-Error auftritt, bin ich auf das "Debugging" mit den Textdateien gekommen.

    Bei Zugriff auf nicht freigegebene Dateien (im User-Context) wirft das Script einen ganz "normalen" Excel-Fehler (Zugriff wg fehlender Rechte verweigert)

  • Muss ich am Montag mal ausprobieren. (wenn ich einen Test-Server finde, auf dem ich Office installieren darf... :)

    Mit Local System gibt es aber immer etwas Probleme, meist dann, wenn es etwas zu bestätigen oder anzuzeigen gibt.

    Im Taskmanager habt ihr ja sicher geschaut, ob die Excel.exe am Laufen ist...

    Kleine Frage:
    Ist es ein Server 2008 R2 oder noch ein älterer? (32bit/64bit?)

    There exist 10 different kind of people on earth.
    Those who understand binary, and those who don't.

    Einmal editiert, zuletzt von ahe (3. Mai 2013 um 18:11)

  • Zitat

    Im Taskmanager habt ihr ja sicher geschaut, ob die Excel.exe am Laufen ist...

    ja, das ist ja das seltsame....Excel läuft lt. Taskmanager.
    Was ich herausgefunden habe, ist dass es, wie du schon bemerkt hast, Probleme gibt bei Anzeigen wie einer msgbox bspw. Dann bleibt das Script auch stehen, daher habe ich es prophylaktisch mal als CUI kompiliert, half auch nichts.
    Ich vermute, Excel startet und zeigt irgendein Fenster an, welches wir ja nicht sehen, da aus dem Taskmanager gestartet wird.
    Wir haben auch schon eine Batch erstellt, in der das Script aufgerufen wird. Das Batchfile von Hand gestartet läuft, aus dem Taskmanager gestartet bleibt es stehen...

  • Im Gegensatz zu Vista/W7 klappt das mit der Sicht auf Message-Boxen und Progress-Bars nur dann, wenn man auf der Admin-Konsole ist oder direkt am Server sitzt.

    Ich installiere des Öfteren als "Local System" User (über einen Dienst), Software auch auf Servern. Bin ich dort aber nicht auf der Konsole angemeldet, so sehe ich keine meiner generierten Meldungen!

    Falls ihr also per RDP auf dem Server seid, versucht einmal den Konsolen Parameter zu nutzen: Mstsc.exe /admin

    Allerdings muss der Rollendienst Terminalserver dafür installiert/aktiviert sein. http://support.microsoft.com/kb/947723/de

    (das hat uns auch schon Nerven gekostet...)

    There exist 10 different kind of people on earth.
    Those who understand binary, and those who don't.

  • Schon mal vielen Dank, wir werden das ausprobieren!