Autoit läuft Fehlerhaft bei Remote Verbindung über Windows auf einen Windows Root Server; aber fehlerlos über den Browserzugang

  • Hi Leute,

    ich habe mir testweise einen Root Server bei "Netc****" für einen Monat bestellt. Wenn ich mein Skript für Excel (Befehle: "Send(Text, Enter, Right, Left, Down)) über die Remote Verbindung vom Windows 11 Betriebssystem auf meinen Windows Root Sever laufen lasse, läuft mein Skript fehlerhaft, ab dem Moment, wo ich das Remote-Fenster minimiere, meinen PC mit dem ich verbunden bin runterfahre oder die Remoteverbindung beende; sodass bspw. die Tasten nicht gedrückt werden können. Es scheint so, als würde hier mein Root Server sein Bildschirm oder seine Tastatur verlieren, wenn ich bspw. die Remote Verbindung abbreche.

    Doch wenn ich meine Skript über den Browser Zugang von meinem Root Server Anbieter starte(über "Bildschirm"/Server Control Panel) , anstatt über die Remote Verbindung von Windows; läuft mein Skript auch dann fehlerfrei, wenn ich das Browser Fenster schließe und meinen Haupt-PC herunterfahre.

    Kennt jemand von euch das Problem und hat eine Lösung dafür? Der Browserzugang ist sehr schlecht und hat viele Nachteile, sodass ich eigentlich lieber diesen vermeiden wollen würde und immer über die Remote Verbindung von Windows auf meinen Root Server zugreifen wollen würde. Wie kann ich es schaffen, dass mein Skript auch bei der Remote Verbindug über Windows fehlerfrei läuft, auch wenn ich bspw. nach dem Start des Skriptes die Verbindung abbreche?

    Ich danke euch im voraus.

    Gruß Bernd

  • Moin Bernd.

    "Dein Script" bei der oben genannten Problematik sieht sehr gut. Ist alles nachvollziehbar. Oder hat mir die Kristallkugel das falsche Script eingeblendet?

    Lieben Gruß,
    Alina

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Geheime Information: ;)
    OuBVU5ebLhHu5QvlnAyQB4A7SzBrvWulwL7RLl2BdH5tI6sIYspeMKeXMSXl

  • Das Script funktioniert auch normal bei dem Windows Root Server über die Remote Verbindung von Windwos; nur wenn ich dann die Verbindung abtrenne, damit das Script im Server im Hintergrund läuft; kommen Fehler, wie dass er die Tasten nicht drückt. Ich habe dabei bemerkt, dass Autoit ganz normal weiterläuft und die Schleifen sich immer weiter wiederholen, während ich das Fenster schließe; aber anscheinend mit fehlerhafter Tastatureingaben(Keine). Bei der Browser Nutzung des gleichen Severs habe ich das Problem nicht.

  • Wenn einige von euch auch Autoit über einen Windows Server über eine Windows-Remote Verbindung benutzen: Habt ihr auch dieses Problem von mir oder nicht? Wenn bei euch alles funktioniert, könnt ihr mir euren Server Anbieter und das auf eurem Server installierte Betriebssystem bitte nennen? Oder könnt ihr Remote Programme nennen, bei denen dieses Problem nicht auftritt?

  • Hallo Bernd,

    das liegt sicher daran, das dein Script im Usermodus ausgeführt wird und nicht im Consolenmodus.

    Startest du dein Script per Taskplaner/Aufgabenplanung?

    Hier musst du die rot umrandeten Einstellungen setzen.

    Das wird für die "Send" Befehle nicht unbedingt die Lösung sein.

    Wohin, an welche Anwendung sendest du denn deine "Send" Befehle ab? Wenn das auch Excel ist, dann kannst du ja die Function _Excel_RangeWrite benutzen.

    Hast du die Remote mal mit den Schalter "mstsc -v:MACHINE_NAME /F -console" verbunden?

    Gruß gmmg

  • Kann Bernd Albrecht Problem komplett nachvollziehen. Hatte damit vor Ewigkeiten zu kämpfen. Das hängt mit der Remote Desktop Verbindung zusammen - ist dann auch egal ob es Send-Befehle oder andere Commands sind. @gmmg's Vorschlag klingt ziemlich gut. Wenn das klappt, wäre das eine interessante Neuigkeit. Rückmeldung wäre dann super.

    Grüße autoiter

  • Startest du dein Script per Taskplaner/Aufgabenplanung?

    Nein, ich starte das Scipt und lasse es quasi unendlich lang laufen. Ich kann mir vorstellen, dass deine Lösung so funktioniert; nur in meinem Fall passt es eher nicht. Trz, danke. Außerdem, wenn ich das Skript auf deine Methode starte, und dann bloß mich während des laufenden Skriptes mich über Remote anmelde; kommt wieder der Fehler.

    Hast du die Remote mal mit den Schalter "mstsc -v:MACHINE_NAME /F -console" verbunden?

    Nein, für was ist dass? Was muss ich dafür genau tun? Hat das auch mit dem Aufgabenplaner zu tun? Wenn ja, wird mir das nicht weiterhelfen

    Ich möchte von der Remoteverbindung mein Skript starten, weil die Remoteverbindung viel besser ist als die Desktop Verbindung über Netcup.

    Ich bin mir ziemlich sicher, dass es mit der Auflösung und dem Display zu tun hat. Wenn ich das Autoitskript in einer Remoteverbindung starte, dann ist die Grundlage für das Ausführen des Skriptes die Auflösung und das Display meines aktuellen Monitors. Ich besitze 3 Monitore und schiebe die Remoteverbindung auf einen davon. Diese Auflösung ist unterschiedlich zu der eigentlichen Auflösung des Servers im "Ruhemodus", also ohne Remoteverbindung. Die Remoteverbindung passt sich ja dem Display und der Auflösung des aktuellen Monitors an.

    Sobald dann die Remoteverbidnung getrennt wird oder sogar zum Server hergestellt wird, während das Skript läuft; sodann entstehen Programmfehler bei Autoit.

    Ich habe nun mein Skript in der Remoteverbindung laufen lassen, und es kam schon zu fehlerhaften Ausführung; als nur sich das Display nach 3 Minuten ausgeschaltet hat und der Rechner und die Verbindung an sich nicht gestört wurden. Daher vermute ich stark die Ursache im Display und der Auflösung.

    Oder liegt die Ursache darin, dass ich 3 Monitore an meinem Rechner verbunden habe?

    Wenn irgendjemand eine Idee hat, wie dieses Problem lösbar ist; wäre das toll.

    Gruß Bernd

  • nun ja ich denke eher das hier die send befehle dein Problem sind.


    Wenn dein PC in den stromsparmodus geht kannst du keine Send befehle benutzen du musst das anders lösen.
    Denn auch wenn ich mich auf einen Rechner anwähle über Remote dann ist auf dem Monitor vom Zielpc zu sehen das sich der Benutzer abmeldet vom System, oder zu mindestens keine eingaben mehr zulässt.
    der Desktop selber ist dann auch nicht mehr zu sehen nur noch der anmelde Bildschirm.

    Du solltest den Skript so aufbauen, das du theoretisch auf auf deinem normalen platz auch ohne Einschränkungen weiter arbeiten kannst auch wenn das Skript im Hintergrund läuft,
    Wenn du eine Exceltabelle ausließt und diese dann verarbeitest muss du nicht unbedingt mit send arbeiten, das ist kompliziert und lässt den Nutzer selbst mehr Fehlerquellen offen.

    Ich weiß auch immer noch nicht was du mit diesem Script erreichen möchtest. macht bisher für mich 0 sinn.

  • über den Browser Zugang.
    Wie genau machst du das hast du das evtl. mit unraid?

    Falls ja dann meldet sich dein windows auch nicht mit einem anderen nutzer an, oder geschweige den wird neu angemeldet.

    Die Maschine läuft ja dort über den Browser normal weiter so als würde sie physisch vor dir stehen.

    Das wäre ein Grund warum darüber noch alles funktioniert.

  • Die Maschine läuft ja dort über den Browser normal weiter so als würde sie physisch vor dir stehen.

    Es (Windows Server) läuft quasi non Stopp, außer ich fahre es über das Control Panel herunter. Es läuft auch, wenn ich den Browser schließe. Gerade läuft Autoit; gestartet über den Browser; seit 2 h fehlerfrei und ganz normal und ich kann den Browser schließen oder meinen physischen Rechner herunter fahren; ohne das es Auswirkungen darauf hätte. Mit einer Remoteverbindung ist dies für mich so aktuell nicht möglich.

  • Also mal zur Erklärung:

    Wenn du Remotedesktop verwendest wird für die Anmeldesession am Server ein virtuelles Display und eine virtuelle Tastatur erstellt. sobald die Remote Verbindung getrennt wird scheitern alle Autoit Funktionen, die auf diese virtuellen Geräte zugreifen, da sie nur während einer aktiven RDP Session existieren. Es macht schlichtweg keinen Sinn Bildschirm und Tastatur bei einer inaktiven (getrennten) RDP Verbindung zu simulieren, daher wird das von Microsoft auch nicht getan. Beim Minimieren des Fensters passiert ähnliches, die virtuellen Geräte werden abgeschaltet (vergleichbar mit Standby) um unnötige Bandbreite der RDP Verbindung einzusparen, denn dein Client braucht schlichtweg kein Bild und keine Tastatur, wenn du den Client nicht aktiv nutzt, weil minimiert.

    Dein Script würde am lokalen Rechner ebenfalls scheitern, wenn du den Rechner sperrst oder auf einen anderen Benutzeraccount wechselt. Dein Account und das Script laufen zwar dann noch im Hintergrund, aber Display und Tastatur sind nicht mehr mit diesem Account, sondern mit dem anderen Account oder dem System Account (Anmeldebildschirm) verbunden.

    Wenn dein Script abhängig von der Auflösung ist können Änderungen zur Laufzeit ebenfalls Probleme machen, diese hättest du aber auch lokal am Rechner, wenn du die Bildschirmauflösung einfach änderst solange das Script läuft. Das lässt sich Programmtechnisch aber evtl. fixen indem du in Intervallen (oder besser auf ein Windows Event) die derzeit verwendetet Auflösung prüfst und dein Script dynamisch darauf reagieren lässt. Einfacher ist es aber auf den Vollbildmodus der RDP Verbindung zu verzichten und diese auf eine feste immer gleich bleibende Auflösung einzustellen.

    Warum passiert das nun nicht auch wenn du über KVM Lösungen des Serveranbieters auf den Server zugreifst? Hierbei verwendest du eine sogenannte Konsolensitzung, d.h. die Anmeldesession ist nicht rein virtuell, sondern identisch mit einer Anmeldung direkt am Server per angeschlossener Tastatur und Maus. Windows geht in solch einem Fall davon aus, dass Monitor und Tastatur nur dann nicht gebraucht werden, wenn der Server in den Standby wechselt, was bei Server Betriebssystemen in der Regel deaktiviert ist. Die Bildschirmauflösung der virtuellen Verbindung ändert sich hier in der Regel auch nicht, da KVM oder VNC Clients maximal einen Softwarezoom anbieten, die eigentliche Auflösung des Displays aber nicht anfassen (sieht man daran, dass bei Größenänderungen das Bild unscharf wirkt). Die Regeln für den Sperrbildschirm oder Benutzerwechsel gelten aber auch hier... Display und Tastatur ändert den Fokus auf einen anderen Account und dein Script scheitert.

    Mögliche Lösungen für dich:

    1. Verzichte auf jegliche Art von simulierten Tastatureingaben und Bildschirmabhängigen Funktionen. In deinem Script Ausschnitt sind das alle "send" Befehle... ersetze diese durch Alternativen der Excel UDF und dein Problem ist gelöst

    2. Teste wie oben beschrieben ob eine RDP Verbindung mit dem Paramater "console" zum selben Ergebnis führt wie bei einer KVM Sitzung:
    "mstsc -v:MACHINE_NAME /F -console"

    3. Verwende Alternativen zu Microsoft RDP für den Serverzugriff. Das Stichwort ist VNC. Auch hier hast du in der Regel eine Konsolensitzung wie bei der KVM Lösung des Serveranbieters, bist aber nicht auf einen Webbasierten Client hierfür angewiesen.

    5 Mal editiert, zuletzt von misterspeed (10. August 2022 um 07:14)

  • Hallo Zusammen,

    misterspeed, gut Erklärt.

    Bernd, der Befehl startet die Remoteverbindung mit dem Schalter "Console". dazu einfach mal ein CMD Fenster öffnen und wie im Bild die Eingaben machen.

    Wie schon vorher gefragt. Wenn du uns noch mitteilst, in welche Anwendung deine Send Befehle abgesendet werden, könnten wir sicher noch weiter helfen :)

    Hier gibt es auch etwas dazu aus dem Engl. Forum: https://www.autoitscript.com/forum/topic/20…when-minimized/

    Du kannst auch noch versuchen das Send durch ControlSend zu ersetzen, bzw. MouseClick durch ControlClick.


    Gruß gmmg

  • 1. Verzichte auf jegliche Art von simulierten Tastatureingaben und Bildschirmabhängigen Funktionen. In deinem Script Ausschnitt sind das alle "send" Befehle... ersetze diese durch Alternativen der Excel UDF und dein Problem ist gelöst

    2. Teste wie oben beschrieben ob eine RDP Verbindung mit dem Paramater "console" zum selben Ergebnis führt wie bei einer KVM Sitzung:
    "mstsc -v:MACHINE_NAME /F -console"

    3. Verwende Alternativen zu Microsoft RDP für den Serverzugriff. Das Stichwort ist VNC. Auch hier hast du in der Regel eine Konsolensitzung wie bei der KVM Lösung des Serveranbieters, bist aber nicht auf einen Webbasierten Client hierfür angewiesen.

    misterspeed vielen dank für deine ausführliche Analyse und Erklärung. Punkt zwei habe ich nun ausprobiert, doch leider bleibt das Problem immer noch. Ich arbeite vorerst über den Webbrowser; in Zukunft werde ich mal "VNC" vielleicht ausprobieren. Vielleicht passe ich mal meine Scripte an, wie du es in Punkt 2 beschreibst.

    gmmg Ich danke auch dir und den anderen für eure Hilfe.

  • Hallo!

    Wie misterspeed schon sehr ausführlich erklärt hat gibt es zwei Arten von Sitztungen: RDP und Console. Die Console kann via KVM (meist ein physikalischer Anschluss der auf TCP/IP umgemünzt wird) oder z.B.: via ESXi eine Console (Webbroser).

    Was schon geht auf einen Server: Du kannst eine RDP-Sitzung auf eine fixe Auflösung stellen und dort Deine Scripts laufen lassen. Jeder Windows Server biete 2 Einstiege an (Remote oder Console). Zur Wartung steigst Du mit einem zweiten User ein, so unterbrichst Du nicht die erste Sitzung.

    Es darf nicht darauf vergessen werden das:

    1.) Kein autologgoff nach einer Zeit (meist 4 Stunden) von der RDP-Sitzung passiert

    2.) Kein Standby (sollten Server sowieso nicht haben)

    3.) Die RDP-Sitzung darf nur getrennt werden und nicht abgemeldet!

    Meiner Meinung nach sollten Serverprogramme immer ohne GUI auskommen, sonst gibt es immer unnötige Probleme nach einen Reboot (der kommt sicher)!

    lg

    Harald

  • Hi,

    Meiner Meinung nach sollten Serverprogramme immer ohne GUI auskommen

    Was sind denn "Serverprogramme"?! Also ich kenne ausschließlich Programme! Und denen ist es absolut und IMMER völlig egal, auf welchem System sie laufen. Wenn diese Programme "remote" benutzt werden, dann ist es Aufgabe des (davon völlig unanbhängigen) Betriebssystems, das komplette Userinterface so weiterzugeben, als ob der User dieses Programm lokal auf seiner Wieauchimmer-Maschine am laufen hat.

    Und dass Windows bei einer Remoteverbindung ein Fenster im Vordergrund braucht, um das AutoItscript fehlerfrei ausführen zu können, sollte bereits aus diversen Postings bekannt sein.

    Ansonsten noch mal ein :thumbup: für Misterspeeds Erklärung und Lösungsvorschläge!

    Weiterhin gebe ich zum "Problem" des TE meinen Senf dazu...langsam wachsen mir die Fransen am Mund bis zum Boden, so oft habe ich das jetzt in den verschiedensten Foren schon wiederholt:

    Wer zur "Automatisierung" von EXCEL (ohne Datenaustausch mit Drittprogrammen) die AutoIt´schen SEND()-Befehle benutzt, hat von Vornherein schon einen an der Waffel!

    Erstens gibt es die M$-Office-übergreifende "eigene" Programmier/Scriptsprache VBA (Visual BASIC (ja, so ähnlich wie das AutoIt-Basic) for Applications), über die man ALLES abwickeln kann (auch ggf. Datenaustausch mit Drittprogrammen) und zweitens haben sich User wie bspw. der geschätzte Kollege Water die nicht unerhebliche Mühe gemacht, die Office-API in eine durchaus für 99% aller Anwendungsfälle benutzbare UDF umzusetzen.

    Hätte der TE, der sich in erlesener Gesellschaft ünzähliger andere Ignoranten befindet, nur EINE dieser Möglichkeiten verwendet, dieser überflüssige Thread hätte nicht erstellt werden müssen!

    Über die Water´sche UDF ist alles gesagt, sie funktioniert!

    Und bzgl. VBA habe ich in den letzten 12 Jahren intensivster Beschäftigung damit noch KEIN Problem gehabt, wo ich nicht nach einigen Minuten Googeln ein fertiges Beispielscript in einem der unzähligen VBA-Foren gefunden hätte!

    Uns jetzt komm mir blos keiner mit "Anfänger" oder "zu blöd/faul/ignorant" zu Googeln! In der Zeit, dieses "Script" aus Post #3 zu erstellen, welches nur ein Ausschnitt mehreren hunderten Zeilen ist, hätte man in entweder einem AutoIt- oder VBA-Forum einen Thread erstellen können:

    "Hallo zusammen, ich möchte folgende EXCEL-Tabelle1 s. Anhang mit mehreren Hundert/Tausend Feldern in einer minimierten Remoteverbindung bzw. direkt auf dem Server nach der Vorgabe blablub (hier gehören Wörter rein, die das Problem beschreiben!!!) bearbeiten. Endergebnis siehe Tabelle2. Bitte um Ideen/Infos/Scripte, wie man das am Besten bewerkstelligen könnte!"

    Nach spätestens einigen Stunden hätte man verschiedenste qualifizierte Lösungsmöglichkeiten gehabt, von denen auch andere User über die diversen Suchfunktionen später mal eine Lösung zu einem ähnlichen Problem hätten finden können.

    Das o.g "Script" und imho auch dieser Thread dagegen sind der Supergau. Ein ultimatives Beispiel dafür, wie es NICHT gemacht werden sollte, auch nicht von einem blutigen Anfänger.

    Vom definitiv vorhandenen XY-Problem mal ganz abgesehen!

    Btw. hätte eine Google-Suche mit "autoit remote script windows" mehrere Seiten Links und Lösungen zum Thema gefunden....